
I 




.Uru I T v^L«ooir»v^M» m»o r«oc 



REPORT DOCUMENTATION PAGE 



t REPORT 5ECURITV CLAS5IPICATICN un^aSSIFIED 


lb. restrictive markings 


SECURITY CLASSIFICATION AUTHORITY 


3. DISTRIBUTION/AVAILABILITY OF REPCRT 

Approved for public release; 
distribution is unlimited 


1. DECLASSIFication/downgrading schedule 


PERFORMING ORGANIZATION REPORT NUMBER(S) 


5. MONITORING ORGANIZATION REPORT NUMBER(S) 


L Name OF PERFORMING ORGANIZATION 
.omputer Science Dept. 

[aval Postgraduate School 


6b. OPFiCE SYMBOL 
(if applicable) 

CS/LE 


7a. NAME OF MONITORING ORGANIZATION 

Naval Postgraduate School 


ADDRESS (City, State, and ZIP Code) 

lonterey, CA 93943-5000 


7b. ADDRESS (City, State, and ZIP Code) 

Monterey, CA 93943-5000 


a. NAME OF FUNDING/SPONSORING 
ORGANIZATION 


6b. OFFICE SYMBOL 
(if applicable) 


procurement INSTRUMENT IDENTIFICATION NUMBER 


ADDRESS (City, State, and ZIP Code) 


10. SOURCE OF FUNDING NUMBERS 


PROGRAM 
ELEMENT NO. 


PROJECT 

NO. 


TASK 

NO. 


WORK UNIT 
ACCESSION N 



1 . TITLE (Include Security Classification) 

lUILDING REUSEABLE SOFTWARE COMPONENTS FOR AUTOMATED RETRffiVAL 



^ PERSON ALAUTHe)P(5J . 
lealander, Jennie Mane 



^ • . 'T V P EgER nW 
faster sThesis 



13b. time Covered 

FROM 09/90 



TO: 09/92 



14. DATE OF REPORT (Yesr, Month. Day) 15. PAGE COUNT 

September 1992 100 



6. sUf^PLEIVlEf^TARY NOTATION 



The views expressed in this thesis are those of the author and do not reflect the official 
policy or position of the Department of Defense or the United States Government. 



COSATI CODES 



FIELD 


GROUP 


SUB-GROUP 















18. SUBJECT TERMS (Continue on reverse if necessary and identify by block number) 

Reusable Software Components, Automated Retrieval, CAPS 



9. ABSTRACT (Continue on reverse if necessary and identify by block number) 

fhe Computer Aided Prototyping System (CAPS) is designed to rapidly build prototypes of real-time sytems throug 
he automated retrieval of reusable software components. A critical element in achieving this goal is a mechanism fc 
lutomated retrieval of reusable software components from a software base. There were two major objectives of thi 
hesis: (1) to select and prepare software components for inclusion in the CAPS software base; (2) to design and in 
ilement a translation tool which takes an Ada specification as input and generates the prototype system descriptior 
anguage (PSDL) interface required for storage and retrieval in the CAPS software base -this is necessary since for 
lomponent to be usable in the CAPS software base, it must be specified in PSDL. We described the abstraction ant 
mplementation of the selected components, introduced the translator, and demonstrated the behaviors of the transl: 
or via examples. 



rDISTRIBUTIONyAVAIlABILlTV OP ABSTRACT 

[3 UNCLASSIFIED/UNLIMITED Q SAME AS RPT. 


□ DTIC USERS 


21. ABSTRACT SECURITY CLASSIPICATICN 
UNCLASSIFffiD 


2a^ NAME Q= RESPONSIBLE INDIVIDUAL 

r un-jeng Lee 


22b. TELEPHONE //nc/L/de Area Code) 

(408) 646-2361 


220^^^ SYMBOL 



0 FORM 1473, 84 MAR 83 APR edition may be used until exhausted SECURITY CLASSIFICATION OF THIS PAGE 

All other editions are obsolete UNCLAS SEFIED 



T258(^59 



Approved for public release; distribution is unlimited 



BUILDING REUSABLE SOFTWARE COMPONENTS 
FOR AUTOMATED RETRIEVAL 



by 

Jennie Marie Sealander 

// 

Lieutenant, United States Naval Reserve 
B.A., Goucher College, 1983 



Submitted in partial fulfillment of the 
requirements for the degree of 



MASTER OF COMPUTER SCIENCE 



from the 

NAVAL POSTGRADUATE SCHOOL 
September 1992 



Qr. Robe rt" B > McGhee^hairman, 
Departmenrof^omputer Science 



ABSTRACT 



The Computer Aided Prototyping System (CAPS) is designed to rapidly build 
prototypes of real-time systems. A critical element in achieving this goal is a mechanism 
for automated retrieval of reusable software components from a software base. There were 
two major objectives of this thesis: (1) to select and prepare software components for 
inclusion in the CAPS software base; (2) to design and implement a translation tool which 
takes an Ada specification as input and generates the prototype system description 
language (PSDL) interface required for storage and retrieval in the CAPS software base - 
this is necessary since for a component to be usable in the CAPS software base, it must be 
specified in PSDL. We described the abstraction and implementation of the selected 
components, introduced the translator, and demonstrated the behaviors of the translator via 
examples. 



Ill 



dJ 

TABLE OF CONTENTS 



I. INTRODUCTION 1 

A. RAPED PROTOTYPING 1 

B. CAPS OVERVIEW 2 

1. User Interface 3 

2. Software Database 3 

3. Execution Support System 4 

C. OBJECTIVES 4 

D. ORGANIZATION OF THESIS 4 

n. SOFTWARE REUSE 5 

A. APPROACHS TO SOFTWARE REUSE 5 

B. RETRIEVING REUS AB ALE COMPONENTS 6 

1. Retrieval Methods 6 

2. Review of Current Systems 7 

C PROTOTYPE SYSTEM DESCRIPTION LANGUAGE (PSDL) 9 

D. CAPS SOFTWARE BASE AND COMPONENT RETRIEVAL 10 

in. REUSABLE SOFTWARE COMPONENTS 14 

A. ENGINEERING SOFTWARE COMPONENTS TO FACILITATE 

REUSE 14 

B. WHY AD A? 15 

C. ADA COMPONENTS SELECTED FOR SOFTWARE BASE 16 

1. Unbounded_Set 16 

2. Bounded_Multiset 17 

3. Bounded_Graph 18 

4. Unbounded_Graph 19 

5. Unbounded_Map 20 

6. Real_Numbers 21 

7. Bounded_Integer 22 

8. Vectors 22 

9. Matrix 23 

IV. PSDL INTERFACE GENERATOR 24 

A. KODIAK 24 

1. Lexical Scanner 25 

2. Attribute Declarations 26 

3. The Attribute Grammar and Equations 27 

B. MAPPING ADA TO PSDL 29 

C. EXPLANATION OF ATTRIBUTES 3 1 

1. psdl_interface_specification 31 

2. file_name 31 

3. generic_type_declarations 31 

4. number_of_operators 31 

5. operator_specification 31 



IV 



6. type_decIarations 32 

7. input_parameters 32 

8. output_parameters 32 

9. exceptions 32 

1 0. variable_type 32 

1 1 . variable_name 32 

12. mode 33 

13. mode_check 33 

14. current_mode 33 

15. composite_types 33 

16. new_composite_types 33 

17. generic_ types 33 

1 8 . ne w_generic_types 33 

19. comma 34 

D. SAMPLE INPUT AND OUTPUT 34 

1 . Operator Example 34 

2. Type Example 36 

E. LIMITATIONS 37 

V. CONCLUSIONS 38 

A. ACCOMPLISHMENTS 38 

B. FUTURE WORK 38 

APPENDIX A. ADA SPECIFICATIONS FOR REUSABLE COMPONENTS 40 

A. UNBOUNDED_SET 40 

B. BOUNDED.MULTISET 42 

C. BOUNDED.GRAPH 44 

D. UNBOUNDED.GRAPH 48 

E. UNBOUNDED.MAP 52 

F. REAL_NUMBERS 54 

G. BOUNDEDJNTEGERS 56 

H. VECTORS 58 

I. MATRIX 60 

APPENDIX B. KODIAK PROGRAM LISTING 61 

LIST OF REFERENCES 91 

INITIAL DISTRIBUTION LIST 93 



V 



LIST OF FIGURES 



Figure 1.1: Software Life Cycle for a Prototype 2 

Figure 1.2: Tools in the Computer-Aided Prototyping System 3 

Figure 2.1: A PSDL Specification for a Set 11 

Figure 2.2: Component Storage 12 

Figure 2.3: Component Retrieval 12 

Figure 4.1: Kodiak Program Structure 25 

Figure 4.2: Examples of Token declarations 26 

Figure 4.3: Example of Attribute Declarations 27 

Figure 4.4: Example of Attribute grammar and equations 28 

Figure 4.5: Operator Template 29 

Figure 4.6: Type Template 29 

Figure 4.7: Example of a generic_parameter_declarations Template 30 

Figure 4.8: Ada Specification for generic bubble sort package 34 

Figure 4.9: PSDL output for Ada generic bubble sort package 35 

Figure 4.10: Ada Specifiation for generic set 35 

Figure 4. 1 1: PSDL output for Ada generic set package 36 



I. INTRODUCTION 



A. RAPID PROTOTYPING 

Developing software systems which are efficient, reliable, maintainable, and 
understandable is a difficult task, especially for reliable real-time systems consisting of 
million lines of code. The development of software tools and methods has emerged in an 
attempt to manage the complexity. One method designed to aid development of reliable 
large sytems is that of rapid prototyping. A prototype is an executable model of an intended 
system whose purpose is to help the system designer and customer to evaluate and validate 
the feasibility of the proposed system. Rapid prototyping is the process of rapidly building 
a prototype of a system. This allows the user to provide feedback to the designer in the 
development phase, reducing wasted effort in building a system which does not meet the 
customers needs. Thus the developement of the system follows an iterative process. The 
designer constructs a prototype based on the requirements, examines the execution of the 
prototype together with the customer, then adjusts the requirements based on feedback 
from the customer. The prototype is modified accordingly until both the customer and the 
designer agree on the requirements [10]. 

The key to rapid prototyping is computer-aided tools and reusable components. An 
efficient way to rapidly build a prototype is to construct the system out of existing software. 
For this to happen, rapid prototyping tools should include a library of high quality reusable 
components in conjunction with an automated retrieval system. A specification language is 
needed to specify the requirements of a system and to locate components which meet the 
specifications. To achieve automated retrieval, components in the library must be stored 
with an interface written in the specification language identifying their functionality. 

The typical software life cycle for such a sytem is illustrated in Figure 1.1. The 
designer takes a set of requirements provided by the customer and generates specifications 
for the system. The prototype is realized by replacing as much of the specification as 
possible with reusable components. The remaining code is written manually. The goal is to 
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build the prototype from as many existing compoments as possible, minimizing the amount 
of code which needs to be written manually. 




Figure 1.1: Software Life Cycle for a Prototype 
B. CAPS OVERVIEW 

The Computer Aided Prototyping System (CAPS) is an integrated set of computer- 
aided software tools being developed at the Naval Postgraduate School. The system is 
designed to rapidly prototype hard real-time systems [9]. The main subsystems of CAPS 
are illustrated in Figure 1.2. The software tools communicate by means of a specification 
language, the prototype system description language (PSDL). The specification language 
allows the designer to formally translate the customer’s requirements into a high level 
description of the system. The specifications are used to retrieve reusable ada components 
from a large software base. An automated transformation scheme then binds the retrieved 
components together based on the PSDL description. The prototype is then compiled and 
executed. The following sections describe each of the three major subsystems of CAPS. 
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Figure 1.2: Tools in the Computer-Aided Prototyping System 

1. User Interface 

The user interface consists of a syntax directed editor, a graphic editor, and a tool 
interface. The graphic editor is used to create a graphic representation of the system in the 
form of a data flow diagram, plus timing and control constraints. Graphical objects used to 
represent the sytem include operators, inputs, outputs, data flows, and operator loops [13]. 
The syntax directed editor provides a convenient way of entering additional annotations to 
the graphics in the form of PSDL descriptions while preventing syntax errors. The tool 
interface hides the details of the interfaces of the CAPS tools from the designer [7]. 

2. Software Database 

The software database system consists of an engineering design database system 
and a software database system [16]. The design database contains PSDL descriptions for 
all software projects developed using CAPS. The software base provides reusable software 
components for realizing given PSDL specifications [9]. The key to component storage and 
retrieval is the component’s PSDL specification [18]. 
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3. Execution Support System 

The execution support system consists of four tools: translator, static scheduler, 
dynamic scheduler, and a debugger [7,16]. The translator generates codes that binds 
together the reusable components extracted from the software base. The static scheduler 
designates time slots for operators with real-time constraints before execution begins. The 
dynamic scheduler allocates time slots for operators that are not time critical. The debugger 
monitors timing constraints and design integrity as the prototype runs and reports failures. 

C. OBJECTIVES 

For a component to be added to the CAPS software base it must be specified in the 
prototyping system description language (PSDL). Writing these specfications is a time 
consuming process. One goal of this thesis is to design and implement a translation tool 
which takes an Ada specification as input and generates the PSDL interface required for 
storage in the CAPS software base. Another goal is to prepare and test Ada components for 
inclusion in the software base. These components must meet certain criteria to be usable in 
a larger system. 

D. ORGANIZATION OF THESIS 

An overview of the design of the CAPS software base and necessary requirements for 
the storage of components in the software base is provided in Chapter n. Chapter IE 
discusses general characteristics required for component reuse, why Ada was chosen as the 
implementation language for the components, and the purpose of these components. A 
description of the design and implementation of the specification interface generator is 
provided in Chapter IV. Chapter V contains conclusions and recommendations for future 
research. 
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II. SOFTWARE REUSE 



A. APPRO ACHS TO SOFTWARE REUSE 

One of the major purposes of software reuse is to reduce the cost of software 
development and maintenance. Software reuse comes in many forms and occurs whenever 
artifacts or knowledge about the development of one system is reapplied in the 
development of another [6]. Examples include the reuse of code, designs, application 
generators, formal specifications, and off the shelf commerical packages. Collectively 
these examples are referred to as reusable software components. 

A report in 1984 stated that “of all the code written in 1983, probably less than 15% 
is unique, novel, and specific to individual applications. The remaining 85% appears to be 
common, generic and concerned with putting applications onto computers” [5]. Thus, 
common generic software is an essential target of opportunity. There is almost no cost 
involved in copying a piece of software. Software reuse also provides a natural way to 
improve the quality of software. Frequent reuse of a software component can lead to 
frequent evaluation and revision, thus resulting in the construction of a high quality piece 
of software. Using high quality, well understood components as building blocks to 
construct large complex sytems should increase the quality of the final product and at the 
same time accelerate software production. 

Technologies applicable to software reuse can be classified into two categories: reuse- 
in- the-small and reuse-in-the-large [6]. Reuse-in-the-smaU is concerned with the reuse of 
small pieces of source code such as classes, subroutines, Ada packages, and so on, and is 
the focus of this thesis. Reuse-in-the-large is concerned both with the reuse of large-grain 
components such as subsystems and the reuse of elements beyond source code such as 
design structures and decisions, domain knowledge, analysis information, and so forth. 

Technologies applied to reuse-in-the-small are basically concerned with component 
representation and component management. Component representation deals with the form 
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and content of software components. There are some important characteristics specific to 
reusable components which will be discussed in Chapter III. Component management is 
concerned with classification, storage and retrieval of software components which will be 
reviewed in the following sections of this chapter. 

B. RETRIEVING REUSABALE COMPONENTS 

There are two costs associated with reuse-in-the-small. The first cost is associated 
with building and maintaing a component for reuse. The second is the cost associated with 
storing and retrieving components. The latter has resulted in an increasing demand for tools 
that aid in classifying, storing, and retrieving components. This section discusses some of 
these methods and the systems which use them [16]. 

1. Retrieval Methods 

Most of the tools developed to assist in the retrieval of software components use 
one or more of three different approaches: browsers, informal specifications, or formal 
specifications. A brief description of each follows: 

a. Browsers 

A browser is a tool, usually window based, for looking through a collection 
of software components. The purpose of a browser is to allow the user to direct a search 
through the available components. This can be useful for a user who is familiar with the 
content and structtire of a software collection. However, this method of retrieval is not 
suited for a very large software base. The user can easily miss semantically similiar 
components stored in separate areas of the software base. Also a user will not know when 
to stop looking for a component unless the component is found or the entire software base 
has been viewed. 

b. Informal Specifications 

Retrieval methods based on informal specifications require the user to list 
some attributes of the component sought. These attributes are used to direct the user to the 
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approriate components. Examples of this method include keyword search, mulit-attribute 
search, and natural language interface. 

To perform a keyword search, a user specifies a list of words relevant to the 
component being sought. For example, a user looking for a component which implements 
a mathematical set, would list the keyword set. A major disadvantage to keyword search is 
that the choice of words listed is crucial to success. One keyword may lead to the retrieval 
of many inappropriate components that the user must review. On the other hand, the use of 
too many keywords may result in missing appropriate components. 

A multi-attribute search is an extension of the keyword search. Attributes 
such as component class (procedure, function, package, etc.) or the number and types of 
parameters are used in the search. This type of search is generally more selective but 
requires the user to be familiar with the classification and storage techniques of the system. 

A natural language search is based on a natural language query formed by the 
user. Although a user may find it easy to formulate a query using a natural language, this 
type of technique is very difficult to implement. Mechanisms built based on this method 
have been limited to certain domains or the use of a restricted language. 

c. Formal Specifications 

Retrieval using formal specification provides for a higher degree of 
automation. The user formulates a query using a high level language to specify the 
functionality of the desired component. Each component in the software base is stored with 
an interface using the same specification language. The system looks for components in the 
software base whose specification matches that of the user’s query. However, writing 
formal specifications for components is difficult and requires substantial training. 

2. Review of Current Systems 

This section describes current retrieval systems that have been built and the 
methods used by each system. 
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a. Draco 



The Draco project was developed at the University of California, Irvine and 
was one of the first systems to reuse components from all phases of the software lifecycle, 
including designs and analysis information. The system organizes software components by 
problem areas or domains. The retrieval scheme is based on a mulit-attribute search. A 
classification scheme, called faceted classification, is used to aid in organizing and 
retrieving components. Each component is described by using a set of attributes. The set of 
attributes is defined by the problem domain. The values associated with attributes are 
selected from a controlled vocabulary. 

The system is conceptually simple to use and relatively easy to implement. 
However, classification is generally not suitable for unconstrained domains. Also, 
semantically similar components may be missed, especially if stored in different domains. 

b. RAPID 

RAPED (Reusable Ada Packages for Information System Development) is an 
ongoing project sponsored by the U.S. Army Information Systems Software Development 
Center in Washington. The system is designed to classify, store, and retrieve reusable Ada 
packages in the information systems domain. RAPID uses a faceted classification scheme 
similiar to Draco. 

c. Operation Support System 

The Operation Support System (OSS) is an ongoing project being developed 
by the Naval Ocean Systems Center. One goal of the project is to establish a Navy software 
library. Currently the components stored in the library are large command, control, and 
communications software subsytems. The system supports component retrieval using 
faceted classification, keywords, and a textual browser. 
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d. Common A da Missile Packages ( CAMP) 

The Common Ada Missile Packages is an ongoing project sponsored by the 
Department of Defense to develope a software engineering system supported by a software 
library of reusable Ada components. The system is directed to software for missile sytems. 
One of the main components of the system is the Parts Engineering System (PES) Catalog. 
The catalog system provides a menu driven interface for storing, modifying, and retrieving 
components. Each component has an attribute list associated with it which is used as the 
basis for retrieval. The method of retrieval is based on muli-attribute search since one or 
more attributes may be used to drive a search. 

e. CAPS 

The method used in the Computer Aided Prototyping System is to retrieve 
components from a software base using a formal specification.The System also supports 
keyword searches and component browsing. The aim of CAPS is automated retrieval and 
integration of a component into a prototype based on formal specification. A description of 
the specification language PSDL is in section C and the basics of the retrieval sytsem will 
be discussed in section D of this chapter. 

C. PROTOTYPE SYSTEM DESCRIPTION LANGUAGE (PSDL) 

The prototype system description language (PSDL) and a large software base of 
reusable components form the basis of the CAPS system. PSDL is a specification language 
that was designed to support rapid prototyping of large real-time sytems [8,10]. PSDL 
contains a small set of powerful constructs which make it simple and easy to understand. 
The language was also designed for specifying retrieval of reusable modules from a 
software base. 

PSDL is based on a computational model consisting of operators and data streams. A 
system is designed as a network of operators connected by data streams augmented with 
timing and control constraints. Operators can be either atomic or composite. A composite 
operator may be decomposed into a set of lower level operators and streams. An atomic 
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operator cannot be further decomposed. The network can be graphically represented as a 
set of data flow diagrams. The prototype as a whole is yiewed as an operator which is the 
top level of the data flow diagram. The top level operator is decomposed into a set of more 
refined operators, and these are decomposed iteratively until all operators are atomic. 

Operators can be either functions or state machines. The data streams can carry 
exception conditions or values of abstract data types [9], A data stream which carries an 
instance of an abstract data type is defined as a PSDL type. This definition includes all of 
the operators that can operate on that data type. PSDL operators and types are the basic 
building blocks of a prototype. 

A PSDL implementation of a prototype has two parts: a network consisting of the 
operators in the sytem and their interconnections, and a set of reusable components 
containing implementations of the atomic components in Ada. The Ada components are 
retrieved from the software base based on a PSDL description provided by the designer for 
each atomic component. The specification part of a PSDL component contains several 
attributes that describe the interface and behavior of that component. Figure 2.1 shows an 
example of a PSDL specification for an abstract data type for a set 

D. CAPS SOFTWARE BASE AND COMPONENT RETRIEVAL 

The CAPS software base is an object-oriented database which contains PSDL 
descriptions and code for all available reusable software components. The database 
management system supports automatic retrieval and provides graphical tools for browsing 
and doing keyword searches [14]. Graphical tools provide a means for storing components 
in the software base as well. 
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type SET specification 

operator EMPTY specification 
output SI : set end 

operator ADD specification 

input ELEMENT : integer, SI : set 
output S2 : set end 

operator IN specification 

input ELEMENT : integer, SI : set 
output RESULT : boolean end 

operator SUBSET specification 
input SI, S2 : set 
output RESULT : boolean end 

operator EQUAL specification 
input SI, S2 : set 
output RESULT ; boolean end 

keywords SET, INTEGER 

description {Implements a set of integers) 

axioms 

(obj SET is sort Set. 
protecting INT. 
op empty : -> Set. 
op add : Int Set -> Set. 
op in ; Int Set -> Bool, 
op subset : Set Set -> Bool, 
op equal ; Set Set -> Bool, 
vars si s2 : Set. 
vars el e2 ; Int. 
eq in (el, empty) = false. 

eq in (el,add(e2,sl)) = or (= =(el,e2), infel^l)). 
eq subset(empty,sl) = true. 

eq subset(add(el,sl),s2) = and(in(el,s2),subset(sl,s2)). 
eq equal(sl,s2) = and (subset(sl,s2),subset(s2,sl)). 

endo) 

end 



Figure 2,1: A PSDL Specification for a Set 
To store a component in the software base requires three files. A PSDL specification, 
and the interface and body for the implementation code [17]. The PSDL specification gives 
a means to uniformly specify the functionality of the component as described in the 
interface code. The PSDL specification is passed through syntactic and semantic 
normalization before being stored in the software base (see Figure 2.2). The normalization 
process modifies the specification to improve the efficiency of the search. A query for a 
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library component is formed by constructing the PSDL specification for the desired 
component. The query specification is normalized then matched against the stored 
specifications (see Figure 2.3). 




Figure 2.2: Component Storage 




Figure 2.3: Component Retrieval 

The retrieval process is two phased [11,17]. Syntactic matching takes place first and 
partitions the software base quickly in order to narrow the list of possible candidates that 
will be considered during semantic matching. The syntactic phase uses the number and 
types of parameters associated with each component to narrow down the search. The 
semantic matching phase uses the axioms in the latter half of a PSDL specification (see 
Figure 2.1) to narrow the set of candidates further. This phase determines which 
components are behaviorally close to the query. 

The ability to accurately specify reusable components with PSDL is critical to the 
success of automated retrieval. The CAPS software base was designed to store components 
implemented in various programming languages. Because of the differences in the 
capabilities of different programming languages, the software base is separated into 
language domains. PSDL is not geared toward any particular programming language and 
therefore must be refined to specify a particular programming language. The software base 
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is designed to recognize the enumeration of PSDL for any language in the following areas: 
generic parameters, abstract data types, type inheritance, and array abstract data type [ 14]. 
For a particular language library the definitions of the special identifiers are contained in a 
rule file for each library. The rule file established for the Ada library guided the tr anslation 
of Ada specs into a PSDL interface (see Chapter IV). 
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m. REUSABLE SOFTWARE COMPONENTS 



A. ENGINEERING SOFTWARE COMPONENTS TO FACILITATE REUSE 

To fully derive the benefits of reusable software components, we must engineer our 
software with reuse in mind and begin to accumulate a rich set of components for the 
designer [1]. There are three factors which make it practical to formalize reuse -in-the- 
small: the emergence of a widely accepted body of knowledge about data structures and 
algorithms, development of software engineering principles, and the development of 
programming languages, such as Ada, which support reuse. Components built for reuse 
should exhibit the characteristcs of any good piece of software. For example, a component 
should be maintainable, efficient, reliable, understandable, and, of course, correct. 

A reusable component should be cohesive and loosely coupled. Cohesive means the 
component should denote a single abstraction. Loosely coupled means the component 
should be defined independently of other abstractions. For example, a component which 
denotes an abstraction for real numbers should not include an abstraction for a set. 
Secondly, the abstraction should not be dependent on other abstractions. 

There are other desirable characteristics of reusable components. They should be 
sufficient, complete, and primitive [1]. These characteristics of a component have to do 
with the outside view of the component. A sufficient component captures enough 
characteristics of the abstraction to permit meaningful interaction with the object. For 
example, if a component represents real numbers but provides no means for adding two real 
numbers together, then the component is useless. The interface of a complete component 
captures all characteristics of the component. Sufficiency implies a minimal collection of 
operations, whereas a complete set of operations is one that covers all aspects of the 
underlying abstraction. 

Primitive operations are those that can be effiiciently implemented with only access 
to the underlying representation. For example, the addition of two real numbers. Those 
operations which are not primitive but may be useful to the component can be easily 
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extended by the user of the component by building new composite operations. For example, 
the abstraction of real numbers includes the notion of comparing two numbers. To make 
the component sufficient it should include “<”and “=” operations. To enhance the 
completness of the abstraction, we might add a “>” operation. However, a “>” can be built 
as a composite operation of the “<” and “=” operations. The designer of a reusable 
component cannot know exactly how a particular component is going to be used. 

B. WHY ADA? 

Ada is a language that embodies and enforces modem software engineering 
principles. Ada was also designed with the explicit requirement to support reuse. Features 
of Ada which support reuse include [1,2]: 

1. Separation of interface from the body, 

2. Generic program units, 

3. Strong typing, and 

4. Variety of program units including packages and subprograms 

Separation of the interface from the body suppons information hiding and abstraction. 

An ada specification (interface) identifies the functionality of a component and is the 
information visable to the user of that program unit. The body contains the unit 
implementation which is hidden from the user. Unimportant details are hidden from the 
user. Separation of the interface from the body is also important for storing and classifying 
a component. 

The Ada generic unit is the main mechanism for building reusable components. A 
generic unit provides the template for the algorithm or data structure. Upon instantiation of 
a generic unit the client provides the set of allowable values for a data structure. 

Ada is a strongly typed language. This means objects declared of a given type may 
only take on those values which are legal for that type. In addition, the only operations that 
may be carried out on an object are those which are defined for its type. Strong typing can 
be instrumental in improving the reliability of a program unit by guaranteeing that the 
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properties of an object are not violated. The requirement for explicit declaration of objects 
with their types improves the readability of a program. This guarantees the programmer 
must say something about the property of an object. 

Packages permit the encapsulation of a group of logically related entities which 
directly supports data abstraction and information hiding. Well structured Ada systems are 
decomposed into levels of abstractions, structured as collections of logically related 
packages that form a model of reality. 

C. ADA COMPONENTS SELECTED FOR SOFTWARE BASE 

The components selected and tested as a part of this study for inclusion in the CAPS 
software base all represent an abstract data type. They include an unbounded map, an 
unbounded set, a bounded multiset, a bounded graph, an unbounded graph, a matrix, vector, 
real numbers, and bounded integer types. All components were developed by students at 
the Naval Postgraduate School. The author of this thesis tested and in most cases modified 
the components. Operations were added to components which did not sufficiently define 
the abstraction. Other changes corrected errors and improved efficiency and readability. 
Appendix A contains the specification for each component. The following is a brief 
description of the abstraction, implementation, and major changes made to the components. 

1. Unbounded_Set 
CL The abstraction 

The mathematical abstraction set is widely used in computer science 
applications. Many interesting data structures can be thought of as just implementations of 
sets. Thus it makes sense to build a reuseable set component. Given a “universe” of 
permissable values, a set is an unordered collection of objects belonging to that universe. 
Two sets are said to be equal if they have the same members. A set is said to be empty if it 
has no members. What are the important operators associated with sets? Certainly adding 
and removing an element from a set are essential as well as being able to determine the size 
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of the set. Other important operations include the dyadic operations union, intersection, 
difference, and equality. 

b. Implementation 

The Unbounded_Set was implemented with a linked list structure. The 
number of elements that can be added to the set are only limited by available memory. The 
unit contains one generic type parameter which defines the type of elements which may be 
added to the set. A hashing function could be used to simplify searching for a given 
element, however, it would complicate the algorithms for the dyadic operations. 

c. Major changes 

A remove procedure and a set difference procedure were added to the original 
version to make the component sufficient. An error in the original add procedure which 
allowed duplicate copies of an element was corrected. 

2. Bounded_Multiset 
a. The abstraction 

A multiset is the same as a set except that items contained within a mulitiset 
need not be unique. The size of a mulitset refers to the number of items contained within 
the set. A multiset which contains no items is said to be empty. Operations important for a 
multiset include an empty set constant, a count operation that returns the number of 
instances of a given element in a given multiset, add and remove operation, an operation to 
test equality, and a size operation which returns the number of distinct elements in a 
multiset. 



b. Implementation 

The bounded_multiset is implemented with an array. The unit has two generic 
parameters. Element is a generic type parameter which provides the type of items which 
can be added to the set. Max_Size is a generic value parameter which determines the size 
of the array (the number of unique elements that may be added to the set). 
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c. Major Changes 

The original data structure kept multiple copies of any repeating elements in 
the array. The data structure was changed to keep a count of each element rather than 
keeping mulitple copies of the element. This representation is more efficient for any 
application which contains many copies of an element, for example an inventory record. 
Two procedures, Last_Element and First_Element, were removed from the package 
specification and are now local to the body. They were used in the implementation of the 
data type, but are not part of the definition of the data type, hence should not be visable to 
the user. An overflow exception was added to the add procedure. The function empty _set 
was changed from a predicate function to an empty set constant. Get and put operations 
were removed from the test package and added to the generic package. 

3. Bounded^Graph 

a. The abstraction 

Graphs are an important mathematical structure and are used widely in 
computing problems. A graph is made up of a set of vertices or nodes and a set of arcs or 
edges, which represent connections between the vertices. Our abstraction represents a 
directed graph or a graph in which the edges have direction. Important operations include 
initializing a graph to empty, adding a node, adding an edge, checking whether there is an 
edge between a given pair of nodes, finding the set of nodes connected to a given node via 
an outgoing or incoming edge, removing the edge between a given pair of nodes, and 
removing a node and all of the edges connected to that node. 

b. Implementation 

The bounded_graph is implemented using an adjacency matrix. An adjacency 
matrix is a /I X /I boolean matrix where n represents the maximum number of nodes allowed 
in the graph. If the [j/j element in the matrix is true then there is an edge from vertix i to 
vertix j and false if there is not. A one dimensional array of size n is used to store the values 
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values of each node. The unit has two generic parameters. One is a type parameter which 
allows the user to define the allowable values for the nodes. The other is a value parameter 
of type positive and determines the maximum size of the graph. 

c. Major Changes 

The original version was a machine with a state variable representing the 
graph declared in the specification. The state variable was removed and a parameter 
representing a graph type was added to all functions and procedures. An operator which 
returns an empty graph was added and overflow exception was added to a local procedure 
which is called by the add operation. 

4. Unbounded_Graph 

a. The abstraction 

The abstraction for the unbounded graph is the same as the bounded graph, 
but allows an arbitrary number of nodes to be added to the graph. 

b. Implementation 

The unbounded graph permits an arbitrary number of nodes in the graph. The 
implementation uses an adjacency list. The basic idea of an adjacency list is to list each 
vertex followed by the vertices adjacent to it. This provides the basic information about a 
graph: the vertices and edges. Two linked lists are used. One list links all the nodes in the 
graph. Each node in the graph has an adjacency list, which lists all adjacent nodes. The unit 
has one generic type parameter which imports the allowed values for each node. 

c. Major Changes 

The original data structure was modified to improve readability. An 
adjacency node in the original structure used a pointer to a graph node to identify an 
adjacent vertix. This pointer was removed and replaced with the node element. Type 
declarations used to build the graph data type were moved from the public to the private 
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section of the specification. This hides unnecessary implementation details from the user. 
An unnecessary type declaration was removed to improve readability. 

5. Unbounded_Map 

a. The abstraction 

A map permits one to define arbitrary relationships among otherwise 
unrelated objects. A map is a mathematical function on objects of one type, called the 
domain, yeilding objects of another type called the range [1]. Thus a map consists of a 
dynamic collection of bindings from the domain to the range. Bindings may be added, 
removed, and modified over the lifetime of a map. The extent of a map represents how 
many bindings are in the map and if a map contains no bindings the map is said to be empty. 

Operations include initializing a map to empty, adding a binding to a map, 
finding the range value associated with a given domain value, checking whether a given 
domain value has a binding in the table, finding the number of bindings in the table, and 
removing the binding associated with a value of the domain type. 

b. Implementation 

An unbounded abstraction should permit a map with an arbitrary number of 
domain and range pairs. This can be easily done using a linked list structure whose nodes 
are records containing these pairs. However, to mitigate the time for searching a gigantic 
list for a given pair, the map is represented as a collection of several smaller lists. The 
unbounded map is represented as a set of blocks of lists. Each block is an array where each 
array component acts as a bucket which holds a list of ordered pairs. A set of blocks is 
represented using a linked list. A hashing function is used to determine in which list or 
bucket a map pair will be located. If the hash function returns an index outside the available 
map blocks, a new block is added. 

The generic unit has eight generic parameters. Two type parameters are used 
to import the domain and range types. A value parameter allows the user to determine the 
number of buckets per block. The remaining parameters are generic subprogram 
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parameters. One is a hashing function, the others are get and put procedures for the domain 
and range. 

c. Major Changes 

In the original version, two state variables, NUM_BINDINGS and 
NUM_BLOCKS, were declared in the package body. These variables will reflect 
inaccurate data if more than one instance of the map type is declared. Thus they were 
removed from the body and made part of the data structure of the map type. 

6. ReaI_Numbers 

a. The abstraction 

The real abstraction is a high precision real number type representing the 
standard mathematical domain of real numbers. Real literals are decimals, with at least one 
digit on each side of the decimal. Operations include conversions from Ada float to real, 
addition, subtraction, multiplication, division, and the comparison operators “=” and “<”. 

b. Implementation 

The real number data type is implemented as a record type. The record 
contains three fields: the sign of the number, a digit array containing the digits of the real 
number, and an exponent array. The unit has two generic value parameters, digits and 
max_exponent. Digits represents the minimum required precision and determines the size 
of the digit array. Max_exponent determines the largest number which can be represented. 

The representation will handle numbers ranging up to 10® where e is the max_exponent. 

c. Major Changes 

The original version used separate arrays to hold the whole and decimal parts 
of a real number. The whole array was declared as a non-generic static type. This version 
was simplified by removing the static array and normalizing the position of the decimal. 
This allowed the elimination of five local subprograms and the simplification of others. 
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Type declarations used to build the real data type were moved from the public to the private 
section of the specification. This eliminates unnecessary implementation details from the 
user. 

7. Bounded_Integer 

a. The abstraction 

The bounded integer abstraction represents signed whole numbers of 
standard mathematics. The range of the integers is bounded. Operations include conversion 
from Ada integers to a bounded_integer, addition, subtraction, multiplication, division, 
mod, and the comparison operators “=” and “<”. 

b. Implementation 

The bounded_integer type is implemented using an array. The unit has one 
generic value parameter which specifies the number of decimal digits the representation 
must support. 

c. Major Changes 

Type declarations used to build integer type were moved from the public to 
private section of specification. Many algorithms were rewritten to improve readability. 
This mainly involved the removal of unnecessary local variables. 

8. Vectors 

a. The abstraction 

A mathematical vector is a set of elements which is ordered in the sense that 
each component is assigned a specific position in the set. The dimension of a vector 
designates the number of elements for a given vector. Operations include conversion from 
an array of elements to a vector, vector addition and subtraction, multiplication by a scalar 
(value of the element type), dot product of two vectors, and the mathematical length of a 
vector. 
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b. Implementation 

The vector is implemented using a one dimensional array. The generic unit 
has a generic type parameter which determines the element type. A generic value parameter 
is used to import the dimension of the vector. Generic subprogram parameters are needed 
to define arithmetic operations on the element type. 

c. Major Changes 

An operation to convert an array of objects to a vector was added. 

9. Matrix 

a. The abstraction 

A mathematical matrix can be viewed as a rectangular array of elements, 
having R rows and C columns. Any particular element in the matrix may be referred to 
using to subscripts, the row and column position. Operations on matrices include 
conversion from an array of elements to a matrix, matrix addition and subtraction, 
multiplication by a scalar ( value of the element type), matrix multiplication, and 
transposition. 

b. Implementation 

The matrix type is implemented using a dimensional array. Two generic value 
parameters are used to define row and column length. A generic type parameter defines the 
element type. 

c. Major Changes 

None. 
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IV. PSDL INTERFACE GENERATOR 



The PSDL interface specification generator is a tool which automates the process of 
producing the necessary PSDL interface for the storage of an Ada component in the CAPS 
software base. This chapter describes the design and implementation of the translator. 
Section A provides information, extracted from [4], that is necessary to understand the code 
listed in Appendix B. 

A. KODIAK 

Kodiak is the tool we used to build the translator. It is a fourth generation language 
developed at the University of Minnesota and designed for the purpose of producing 
language translators. The language is based on Knuth’s description of attribute grammars 
[4]. Attribute grammars are a scheme for describing syntax-directed translation, in which a 
context-free grammar’s rules are augmented with equations defining these attributes. The 
string is parsed into a syntax tree by applying a set of grammar rules. The root of the tree 
represents the start symbol, the leaf nodes represent the terminal symbols, and the internal 
nodes represent the non-terminal symbols of the grammar. Attributes can be assigned to the 
nodes of the syntax tree. To translate the input string into an output string, values are 
assigned to the attributes of each node. The root of the tree is given an attribute whose value 
is based on the collective value of all the nodes in the tree, producing the output string. 

The values of a particular node’s attributes can be determined in one of two ways. The 
values of the attributes are either inherited or synthesized. Synthesized attributes are 
evaluated from the bottom up, meaning the value of an attribute at a given node is derived 
from that node’s descendants. Inherited attributes are evaluated from top down, meaning 
the value of an attribute at a given node is derived from the node’s parent. 

Every Kodiak program consists of three sections, as shown in Figure 4.1. The first 
section describes the feamres of the lexical scanner which is used to translate the source 
text into tokens and associativities for those tokens. The second section declares the 
attributes and their type associated with each grammar symbol. The third section describes 
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the grammar and attribute equations which define the semantics of the translation. Each 
section must be separated by a double per-cent symbol {%%) on a line by itself . The 
symbol “!” introduces a comment and everything written after it on a line it will be 
interpreted as a comment. The following is a brief description of each section. 



! Lexical Scanner Section 
%% 

! Attribute Declaration Section 
%% 

! Grammar rules and attribute equations 

Figure 4.1: Kodiak Program Structure 

1. Lexical Scanner 

The lexical scanner section of a program defines the terminal symbols (leaf nodes 
of the syntax tree) of the source language and how these symbols are to be transformed into 
tokens. The source language in this case is Ada and the terminal symbols correspond to 
Ada’s lexical units. Ada’s lexical units consist of identifiers, numeric literals, character 
literals, and comments. Ada’s reserved words, a subset of identifiers, must be defined in 
this section as they are required in defining the grammar. The basic form of a token 
definition is: 

TERMINAL_NAME : REGULAR_EXPRESSION 

Terminal name is the name given to the token and appears in the definition of the grammar 
in section three of the program. The regular_expression provides the definition of the token. 
Code fragments from the lexical scanner section of the PSDL interface generator are given 
in Figure 4.2. These declarations indicate that an occurence of the regular expression to the 
left of a colon is to be replaced by the atomic terminal symbol on the right. For example, 
an occurence of the string “package” or “PACKAGE” in the input text is to be replaced by 
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the symbol PACKAGE. The keyword %define introduces a definition. Square brackets 
enclosing a set of characters indicates that any character of the set may be used to match 
the text. Curly braces are used to invoke a substitution. The ‘+’ operator indicates that one 
or more of the previous class may be used to match the text. The operator indicates that 
zero or more of the previous class may be used to match the text. 



! definition of lexical classes 

%define Digit : [0-9] 

%define Int : { Digit }+ 

[definition of compound symbols and keywords 

PACKAGE : package I PACKAGE 
REAL_LITERAL ; {Int}”.”[Int} 



Figure 4.2: Examples of Token declarations 

2. Attribute Declarations 

The attribute declarations section consists of attribute declarations for all non- 
terminals and terminals named in the program. Kodiak supports two primitive types for 
attributes: strings and integers. Kodiak also supports higher order map types. For example 
in Figure 4.3, generic_type_definitions has two attributes. The attribute variable_type is 
declared to be of type string. The attribute generic_types is declared to be a map type whose 
domain and range are both of type string. Basic_declaration has one attribute, 
number_of_operators, which is declared to be of type integer. 

Terminal symbols may also have attributes. These symbols are permitted two 
predefined attributes called %text and %line in addition to user defined attributes. In Figure 
4.3, the terminal IDENTIFIER has the attribute %text which will be initialized to the text 
the terminal symbol IDENTIFIER matched in the input text. 
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! Attribute declarations for non-terminal symbols 

start { psdl_interface_specification : string; }; 

generic _type_definition { variable_type : string; 

generic_t)T3es : string->string; } ; 

basic_declaration { number_of_operators : int; }; 

lAttribute declarations for terminal symbols 
IDENTIFIER {%text ; string; }; 



Figure 4.3: Example of Attribute Declarations 
3. The Attribute Grammar and Equations 

The attribute grammar section consists of a set of BNF rules defining the grammar 
of the source language. Each rule is associated with a set of equations which define how the 
input text is to be translated. A fragment of the PSDL interface generator is given in Figure 
4.4. The fragment defines the grammar rule for the non-terminal package_specification. 
The symbol “I” is used to separate two definitions for the grammar symbol. Curly braces 
surround any attribute equations. Null productions are permitted, meaning the curly braces 
may be left empty. 

An attribute is referred to using dot notation. The grammar symbol associated 
with the attribute proceeds the dot and the name of the attribute follows. If more than one 
occurence of a grammar symbol appears in a grammar rule, the leftmost symbol is taken to 
be the one referred to by an attribute. To refer to a later symbol, the attribute may be 
followed by a number in brackets referring to the symbols position of occurence in the rule. 

Kodiak supports traditional arithmetic and relational operators for integers and 
strings. An addition operator for map types is provided using the symbol “-1-1”. A 
conditional clause is also supported and is exemplified in Figure 4.4. The then portion of 
the clause follows the arrow and the else portion follows a “#” sign. 
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One attribute equation is defined between the first set of curly braces in Figure 
4.4. The equation evaluates the value for the attribute psdl_interface_specification. This 
equation contains a conditional. If the attribute number_of_operators equals one, then the 
value following the arrow is assigned to the psdl_interface_specification, otherwise the 
value following the # sign is used. Literal strings appear between quotes. The other 
attributes which appear in the equation are evaluated to strings. All literals and attributes 
between the brackets are catenated to produce the psdl_interface_specification. A further 
explantion of the attributes in provided in section C. 



package_specification 

: PACXAGE IDENTIFIER IS basic_declarative_items END IDENTIFIER 
{ package_specification.psdl_interface_specification = 
basic_declaradve_items.nuinber_of_operators = 1 

-> [ “OPERATOR”. IDENTIFIER.%text. ‘^nSPECIHCATION^n’^ 
package_specification.generic_type_decIarations, “Vn”, 
basic_declarative_items.input_parameters, 
basic_declarative_items.output_parameters, 
basic_declaradve_items.exceptions, 

“ENDSn’T 

# [ ‘TYPE ”, IDENTIFIER.%text, ‘^nSPECIFICATION^”. 

package_specification.generic_type_declarations, ‘" mi”, 

basic_declarative_items.type_declarations, 

basic_declarative_items.operator_specifications, 

“ENDVn’l; 

I PACKAGE IDENTIFIER IS basic_declarative_items PRIVATE 

basic_declarative_items END IDENTIFIER 
{ package_specification.psdl_interface_specification = 
basic_declarative_items.number_of_operators == 1 

-> [ “OPERATOR ”, IDENTIFIER.%text, ‘^nSPECIHCATIO^^n”. 
package_specificadon.generic_types_declarations, ‘°Sn”, 
basic_declaradve_items.input_parameters, 
basic_declaradve_items.output^arameters, 
basic_declaradve_items.excepdons, 

“END\n”]; 

# [ “TYPE ”, IDENTIFIER.%text, ‘%nSPECIHCATIONVi”, 

package_specificadon.generic_type_declaradons, ‘^n”, 

basic_declaradve_items.type_declaradons, 

basic_declaradve_items.operator_specificadons, 

“END\n” ]; } 



Figure 4.4: Example of Attribute grammar and equations 
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B. MAPPING ADA TO PSDL 



An Ada specification will be translated into either a PSDL operator or PSDL type 
depending on the number of procedures and functions declared in the specification. If only 
one procedure or function is declared, the specification is translated as a PSDL operator 
using the template in Figure 4.5. The operator will be given the name of the procedure or 
function name in the Ada specification. If the specification contains 0 or 2 or more 
procedures or functions, the specification is mapped to a PSDL type using the template in 
Figure 4.6 . The type will be given the name of the Ada package. 



OPERATOR 

SPECIFICATION 

GENERIC 

generic_parameter_declarations 

Input input_parameters 
output output_parameters 
exception_declarations 
END 



Figure 4.5; Operator Template 



TYPE 

SPECIFICATION 

GENERIC 

generic_parameter_declarations 

type_declarations 

operator_specifications 

END 



Figure 4.6: Type Template 
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variable_names 


• 

• 


GENERIC_VALUE 









Figure 4.7: Example of a generic_parameter_declarations Template 
Each generic declaration in the Ada specification is translated into a single PSDL 
generic type or built into a composite generic type. Generic value and object parameters 
declared in the Ada specification are translated into a single PSDL generic type. The 
parameter name is the same as the parameter in the Ada specification and the type is 
translated as GENERIC_VALUE. Generic type parameters declared in the Ada 
specification are also translated into a single PSDL generic type if they are not part of a 
generic array type definition. The parameter name is the same as the parameter in the Ada 
specification and the type is translated as GENERIC_TYPE. If the index and element part 
of an array type parameter are generic parameters, they are incorporated into the definition 
of the array type of the PSDL. For example given the following Ada declaration: 
generic 

type ELEMENT is (<>); 

type LIST is array (INTEGER range <>) of ELEMENT; 

only one PSDL generic type will be translated from the two generic Ada parameters as 
follows: 

LIST : GENERIC.TYPE [ BASE.TYPE : ARRAY [ 

ELEMENT : DISCRETE, INDEX : INTEGER ]] 

Generic subprogram parameters declared in the Ada specification are translated into a 
single generic PSDL type . The parameter name is the same as the name given in the Ada 
specification, with the exception of overloaded functions named with symbols. Operator 
symbols are translated into strings. For example, a generic subprogram named “+” will be 
renamed to “add”. The type is translated as GENERIC_PROCEDURE. 
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C. EXPLANATION OF ATTRIBUTES 



The following is a brief description of the attributes used to build the PSDL interface 
specification generator. 

1. psdl_interface_specification 

The attribute psdl_interface_specification is the highest attribute and stores the 
result of the translation. The translation is written to a file named with the Ada package 
name concatenated with the suffix “.psdl”. 

2. file_name 

The attribute file_name is a synthesized attribute which provides the name of the 
file the translation is written to. 

3. generic_type_declarations 

The attribute generic_type_declarations is a synthesized suing which builds the 
generic portion of the PSDL specification. 

4. number_of_operators 

The attribute number_of_operators is a synthesized integer used to determine if 
the PSDL specification is that of an operator or a type. This attribute counts the number of 
procedures and functions declared in the Ada specification. If only one procedure or 
function is declared, the operator template, Figure 4.5, is used to build the specification, 
otherwise the type template. Figure 4.6, is used to build the specification. 

5. operator_specification 

The attribute operator_specification is a synthesized string which builds the 
operator specifications for a type declaration. 
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6. type_declarations 

The attribute type_declarations is used to build the non-generic type declarations 
of the PSDL specification. In this implementation only private type declarations are 
translated. They arc translated to the type ADT. 

7. input_paraiTieters 

The input_parameters attribute is used to build the input parameters for each 
operator in the PSDL specification. Ada in and in out variables of procedures and functions 
become the input parameters for a PSDL operator. The name and the type name of a PSDL 
input will be that of the corresponding Ada parameter. 

8. output_parameters 

The output_parameters attribute is used to build the output parameters for each 
operator in the PSDL specification. The name and the type name of a PSDL output will be 
that of the corresponding Ada parameter. 

9. exceptions 

The attribute exceptions provides the exception declarations for a PSDL operator 
interface. Type interfaces do not have exceptions declarations included with the operators 
in this implementation. 

10. variable_type 

The attribute variable_type is a synthesized string which provides the type name 
for variables declared in the generic portion and type declaration of the PSDL specification. 

11. variable_name 

The attribute variable_name is a synthesized string which provides the name for 
each input/output parameter of an operator. 
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12. mode 



The attribute mode is a synthesized map used to determine if there are any input 
or output parameters to an operator specification. It is used to modify the template in 
Figures 4.5 and 4.6. If there are no input parameters, the fixed input portion of the template 
is to be eliminated. If there are no output parameters, the output portion is eliminated. 

13. mode^check 

The attribute mode_check is an inherited map which is used to initialize the 
attribute mode to a default value of empty string. 

14. current_mode 

The attribute current_mode is a synthesized string used to determine if a comma 
is required between two parameters. 

15. composite_types 

The attribute composite_types is an inherited map which is used to determine if a 
generic type declaration in the ada specification is the index or element type of an array 
declaration. This information is used to build an array declaration in the PSDL. 

16. new_composite_types 

The attribute new_composite_types is a synthesized map which is built to provide 
the value of the map composite_types. 

17. generic_types 

The attribute generic_types is an inherited map which provides the type name for 
the index and element part of an array declartion. 

18. new_generic_types 

The attribute new_generic_types is a synthesized map which is built to provide 
the values of the map generic_types. 
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19. comma 

The attribute comma is a synthesized string used to determine if a comma is 
needed between two generic parameters. 

D. SAMPLE INPUT AND OUTPUT 

Two samples of Ada specifications used as input and the respective PSDL interface 
specifications generated are shown below. The first example is translated into a PSDL 
operator, the second into a PSDL type. 

1. Operator Example 

The first example in Figure 4.8 shows an Ada specification for a generic package 
which contains one subprogram and four generic parameters. The generated PSDL 
specification is shown in Figure 4.9. The PSDL specification is an operator and contains 
two generic parameters. The operator specification was a result of only one subprogram 
being declared in the Ada package. The three generic parameters in the Ada generated one 
type definition in the PSDL. This is because the types ITEM and INDEX are used to define 
the array ITEMS. 



generic 

type ITEM is private; 
type INDEX is (<>); 

type ITEMS is array (INDEX range o ) of ITEM; 

with function “<“ (Left : in ITEM; Right : in ITEM) return BOOLEAN; 

package Bubble_Sort is 

procedure Sort (The_Items : in out ITEMS); 
end Bubble_Sort; 



Figure 4.8: Ada Specification for generic bubble sort package 
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OPERATOR Bubble.Sort 
SPECIFICATION 
GENERIC 

ITEMS : GENERIC_TYPE [ BASE_TYPE: ARRAY[ARRAY_ELEMENT : PRIVATE, 
ARRAY.INDEX : DISCRETE ] ], 
less.than : GENERIC.PROCEDURE 

input Thejtems: ITEMS 
output The_Items: ITEMS 
END 



Figure 4.9: PSDL output for Ada generic bubble sort package 



with textjo; use text_io; 
generic 

type t is private; 

block_size : in natural := 128; 

with procedure eq (x,y : in t; v: boolean); 

package sb_set_pkg is 
type set is pivate; 

type index_array is array (natural range <>) of natural; 
procedure empty (s: out set); 
procedure add (x: in t; si: in set; so: out set); 
procedure remove (x: in out t; s: in out set); 
procedure member (x; in t; s; in set; b; boolean); 
pocedure union (sl,s2 ; in set; s3 : out set); 
procedure difference (sl,s2 : in set; s3 ; out set); 
precedure intersecdon (sl,s2: in set; s3: outset); 
procedure size (s: in set; v: out natural); 
procedure equal (sl,s2 : in set; v: out boolean); 
procedure subset (sl,s2: in set; v: out boolean); 

private 

type link is access set; 

type elements_type is array (l..block_size) of t; 
typeset is 
record 

size : natural := 0; -The size of the set 
elements : elements_type; -The actual elements of the set 
next ; link := null; -The next node in the list 
end record; 

-Elements (l..min(size,block_size)) contains data 
end sb_set_pkg; 



Figure 4. 10: Ada Specifiation for generic set 
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2. Type Example 

The second example in figure 4.10 shows an ada specification for an abstract data 
type the “set”. The generated PSDL specification is shown in Figure 4.1 1. Because there is 
more than one subprogram declared in the Ada, the resulting PSDL specifcation is for a 
type. The example shows the translation of generic type, value, and subprogam parameters. 
The private type declaration, set, translated to ADT in PSDL. All subprograms were 
translated to operators. 



TYPEsb set pkg 


OPERATOR intersection 


SPECmCATION 


SPECmCATION 


GENERIC 


input si, s2; set 


t: GENERIC TYPE, 


output s3: set 


block size: GENERIC VALUE, 
eq: GENERIC.PROCEDURE 


END 


OPERATOR size 


set : ADT 


SPECmCATION 




input s: set 


OPERATOR empty 


output v: natural 


SPECmCATION 


END 


output s: set 




END 


OPERATOR equal 
SPECmCATION 


OPERATOR add 


input si, s2: set 


SPECfflCATION 


output v: boolean 


input x: t, si: set 
output so: set 


END 


END 


OPERATOR subset 
SPECmCATION 


OPERATOR remove 


input si, s2: set 


SPECMCATION 


output v: boolean 


input x: t, s: set 


END 


output x: t, s: set 
END 


END 


OPERATOR member 
SPECMCATION 




input x: t, s: set, b: 




OPERATOR union 
SPECMCATION 




input si, s2: set 
output s3: set 




END 




OPERATOR difference 
SPECMCATION 




input si, s2: set 
output s3: set 




END 





Figure 4.11: PSDL output for Ada generic set package 
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E. LIMITATIONS 



Ada is not case sensitive whereas Kodiak is. This presents a problem in parsing legal 
expressions in Ada. For example, the terminal symbol PACKAGE was defined to match 
any occurence of “package” or “PACKAGE” in the input string. However, it is legal in Ada 
to use a mixture of upper and lower case. This will not be selected as a match in this 
implementation. The way around this is to run all Ada specifications through a pretty 
printer first. 

This implementation does not include the grammar for the entire Ada language. The 
grammar selected includes Ada package specifications and generic specifications. This 
implemention does not include keywords, descriptions, exceptions for type declarations, 
and OB J3 axioms. Keywords and descriptions are not used for query by specification, but 
are required for keyword search and browser, respectively. 
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V. CONCLUSIONS 



The use of reusable software components will be crucial to the successful 
development of large software systems. One of the major problems in code reuse is the lack 
of a large library of reusable software components. This problem is aggravated by the fact 
that more effort is required to build a generalized component for reuse then to build one for 
a specific application. A reusable component must be sufficiently powerful to accomodate 
a wide range of applications. A second problem with code reuse is concerned with the 
storage and retrieval of reusable components. Specifically, to automate component 
retrieval, it is necessary to accurately specify the component’s functionality. The CAPS 
system is designed to exploit code reuse for rapid prototyping of hard-real time systems. 
The prototype is built in part by the automated retrieval of reusable Ada components. 

A. ACCOMPLISHMENTS 

As a part of this thesis, reusable Ada components were selected and prepared for 
inclusion in the CAPS software base. However, these components represent a small subset 
of the thousands of components which will be required. Another way to build up the 
number of components in the CAPS software base is to adopt components which are 
already being used in other software libraries. To store these components in the CAPS 
software base they will need to be specified in PSDL. It is important to accurately specify 
a component’s functionality in PSDL since the key to successful retrieval is this 
specification. We have developed a translation tool that is able to generate in part the PSDL 
specification for Ada components. 

B. FUTURE WORK 

There is still a tremendous amount of work which needs to be done in this very labor 
intensive area of building reusable components. Depasquale [3] addresses the issue of 
automating the production of test programs based on a component’s formal specification. 
More work could be done in this area to aid in component testing. If a component is built 
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based on a formal specification then it should be easier to test the component and at least 
part of the Ada code may be automatically generated (see Reference 15). 

The translator should be expanded to include at least some of the limitations addressed 
in Chapter IV. 

The opportunity and benefits for reuse are real. Building systems from reusable 
components should result in higher quality and more reliable systems. CAPS is one 
example of a system realizing these benefits. 
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APPENDIX A. ADA SPECIFICATIONS FOR REUSABLE COMPONENTS 



A. UNBOUNDED_SET 



-<>♦ Title : CS-4530 PROJECT l“UNBOUNDEDSET“ * 

Author : Erhan S ARIDOGAN ^ 

Modifications : Procedure add modified March 92 by J.M. Sealander to prevent replicate * 

-^elements being added to a seL, procedure remove and function difference added to pkg. * 

Date : Novembers, 1991 * 

Course: CS-4530 * 

System : Unix * 

Compiler : Verdixada * 

Description : This generic package provides to create and manipulate * 

unlxDunded mathematical set of a given type. * 

It has two generic parameters£iement_Type and function * 

Equal.The I/O procedures need to use generic procedures. * 

T>^ Unbounded_Set is declared as private ty^. * 

All the required operations are available in the package * 

Link list structure is used to provide unlimited entry. “** 

^ ^ :K 4i 4> ^ 4s ^ 4i an ^ * 4> 4> ^ 9t> « 4> 9t> 4( ^ * 4> :K 



with TEXTJO; 
use TEXTJO: 

generic 

type ELEMENT TYPE is private; 

with function EQUAL( X, Y : ELEMENT_TYPE ) return BOOLEAN is 
package UNBOUNDED_SET_PKG is 
type UNBOUNDED_SET is private; 

~ This array is needed to inidalize a set variable with given values 
type SET_ARRAY is array (NATURAL range o) of ELEMENT_TYPE; 

INVALID_SET_ENTRY. 

REPEATED_ELEMENT : exception: -- used in I/O 

— Operations on seK ( The required ones ) 
function EMPTY return UNBOUNDED_SET; 

procedure ADD( X : in ELEMENT_TYPE; S : in out UNBOUNDED_SET ); 
procedure REMOVE( X : in ELEMENT.TYPE; S : in out UNBOUNDED.SET ); 
function MEMBER( X : ELEMENT.TYPE; S : UNBOUNDED.SET ) return BOOLEAN; 
function UNION( SI, S2 : UNBOUNDED_SET ) return UNBOUNDED.SET; 
function INTERSECnON( SI, S2 : UNBOUNDED.SET ) return UNBOUNDED.SET; 
function DIFFERENCE( S 1, S2 : UNBOUNDED.SET ) return UNBOUNDED.SET; 
function SUBSET( SI, S2 ; UNBOUNDED.SET ) return BOOLEAN; 
function EQUAL( SI, S2 ; UNBOUNDED.SET ) return BOOLEAN; 
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function SIZE( S : UNBOUNDED_SET ) return NATURAL; 
function INinALIZE( A : SET.ARRAY ) return UNBOUNDED^SET; 

-- Input/output routines 

- These routines must be instantiated by using diffemt parameter 

-- procedures for each different Element_Type. 

generic 

with procedure G_PUT( X : in ELEMENT_TYPE ) is o; 
procedure GEN_PUT( S : in UNBOUNDED_SET ); 

generic 

with procedure G_GET( X : out ELEMENT_TYPE ) is o; 
procedure GEN_GET( S : out UNBOUNDED^SET ); 

generic 

with procedure G_PUT_FILE( FILE : in FTLE_TYPE; 

X : in ELEMENT_TYPE ) is <>; 

procedure GEN^FILE_PUT( FILE : in FILE^TYPE; S : in UNBOUNDED.SET ); 
generic 

with procedure G_GET_ETLE( FILE : in FILE_TYPE; 

X : out ELEMENT^TYPE ) is o; 

procedure GEN^FTLE_GET( HLE : in FILE^TYPE; S : out UNBOUNDED.SET ); 



private 

type ELEMENT; 

type UNBOUNDED_SET is access ELEMENT; 

type ELEMENT is 

record 

NODE : ELEMENT_TYPE; - contains the element 
NEXT : UNBOUNDED^SET := null; -- used in link list 
end record; 

end UNBOUNDED^SET^PKG; 
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B. BOUNDED MULTISET 



-Title : Generic specification for bounded_multisets 
-Author : William D. Reese 

-Modification: Modified by J.M. Sealander Apr 92. The original data structure kept mulitple copies 
-of any repeating elements. The data structure was changed to keep a count of each element rather than 
-keeping multiple copies. Get and put operations were removed from the test package and added 
-»to specification. Last_Element and The_Element were removed from the package specifications 
-and are now local to the body. They reflect the implementation method, not the data type. 

-Overflow exception added to proc^ure Add. Function empty_set removed 
- and replaced with empty_set constant. 

-Date : October 12, 1991 
-Course : CS-4530 (Prof. Luqi) 

-System : UNIX 
-Compiler : VERDIX 

• BOUNDED.MULTISETS • SPEC 

* 4i « * « 4i « « « « « 4i « « * 4i 4i * « « 4i « 4i 

generic 

type ELEMENT_TYPE is private; 

MAX.SIZE : POSITIVE; 

with procedure PUT(X; ELEMENT_TYPE); 
with procedure GET(X; out ELEMENT_TYPE); 

package BOUNDED_MULTISETS is 
-Pui^se 

-This package provides facilities for implementing bounded multisets 
-as abstract data types (ADT). Operations provid^ include an empty 
-set constant, functions for adding, removing, and counting elements, 

-as well as comparison for equality between two bounded multisets. 

type BOUNDED_MULTISET is private; 



Count 



SPEC 



function Count (THE BOUNDED MULTISET : in BOUNDED MULTISET; 

ELEMENT_OF_INTEREST : in ELEMENT.TYPE) return NATURAL; 



Add 



SPEC 



procedure Add (ELEMENT_TO_BE_ADDED : in ELEMENT_TYPE; 

THE.MULTISET ; in out BOUNDED.MULTISET); 



Remove 



SPEC 
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procedure Remove (ELEMENT_TO_BE_REMOVED : in ELEMENT_TYPE; 

THE_MULT1SET : in out BOUNDED.MULTTSET); 



Equals 



SPEC 



function Equals (SET_1, SET_2 : in BOUNDED_MULTISET) return BOOLEAN; 



Size . SPEC 



function Size (THE_MULTISET : in BOUNDED_MULTISET) return NATURAL; 



Put_Multiset 



SPEC 



procedure Put_Multiset (MULTISET : in BOUNDED_MULTISET); 



Get_Multiset 



SPEC 



function Get_Multiset (NUMBER_OF_ELEMENTS : in NATURAL) 

return BOUNDED_MULTISET; 



NOT_FOUND : exception; 

OVERFLOW : exception; 

private 

type ELEMENT_RECORD is 
record 

ELEMENT : ELEMENT_TYPE; 

COUNT ; NATURAL := 0; 
end record; 

type LIST is array (INTEGER range o) of ELEMENT_RECORD; 

type BOUNDED_MULTISET is 
record 

THE.ELEMENTS : LIST(1..MAX_S1ZE); 

HOW.FULL : NATURAL := 0; 
end record; 

EMPTY_SET : constant NATURAL := 0; 

end BOUNDED.MULTISETS; 
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C. BOUNDED GRAPH 



with TEXTJO; 
use TEXTJO; 



♦ * 

* Bounded_Graph * 

★ ★ 



SPEC 



generic 

type NODE_TYPE is private; 
max_size : integer; 

package Bounded_Graph is 

- Purpose 

- The routines in this package deal with a directed graphs with a number of 

- nodes <= max_size, which is established at instantiation. The package 
“ specification contaions the followings functions and procedures. 

~ add_a_node 

- add_an_edge 

- remove_an_edge 
remove_a_node 

- nodes_connected_in 
~ nodes_connected_out 
~ nodes_connected 

- graph_empty 

- Notes 

- max_size should be only a positive integer number 

- NODE_TYPE is a user defined type 

- Exceptions 

- DUPLICATE_NODE -- Raised if a duplicate node is added to the graph. 

- NODE_NOT_FOUND -- Raised if a node passed in is not in the graph. 

- GRAPH JS_FULL - Raised if a node is added to a full graph. 

~ GRAPH_IS_EMPTY - Raised if any operation except add_a_node and graph_empty 

- is attempted on an empty graph. 

- Modifications 

- 11/13/91 Michael D. O’Loughlin Initial version of specification. 

- UMX version Verdix Ada, Naval Postgraduate School 

- 02/92 J.M. Sealander Original version was a machine with state variable graph declared in 
—specification. State variable removed and parameter of type Graph_Typ_Ptr added to all functions 
-and procedures. An operator which returns an empty graph was added and overflow exception 
-was added to a local procedure which is called by the add operation. 

type Graph_Typ_Ptr is private; 

DUPLICATE.NODE, 

NODE^NOT^FOUND. 

GRAPH JS.FULL, 

GRAPH_IS_EMPTY : exception; 
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SPEC 



Graph_Enipty 



function Graph_Empty(GRAPH : in Graph_Typ_Ptr) return boolean; 

- Pu^se 

- This function will check if the graph matirx is empty (no nodes on the graph) 



Nodes_Connected 



SPEC 



procedure Nodes_Connected(graph : in out Graph_Typ_Ptr; 

a_node, b_node : in NODE_TYPE; 
conn : out CONNECTION): 



-- Pu^se 

— This function will check if two two nodes are connected. 



! Add_A_Node 



SPEC 



procedure Add_A_Node(graph : in out Graph_Typ_Plr; node : in NODE_TYPE); 

- Pu^se 

- This procedure will add a node to the graph (adjacency matrix). 



Add_An_Edge 



SPEC 



procedure Add_An_Edge(Graph : in out Graph_Typ_Ptr, 

a_node, b_node ; in NODE_TYPE); 



- Pu^se 

- This procedure will add an edge between the two node passed in. 



Nodes_Connected_Out 



SPEC 



procedure Nodes_Connected_Out(graph : in out Graph_Typ_Ptr; 

node : in NODE_TYPE; 
out_nodes ; out NODE_COUNT; 
node_connected : out CONNECl ED_NODES) ; 
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- Pu^se 

" This procedure will pass out all nodes and the number of nodes connected, 

- to the node passed in, by an out edge. 



. Nodes_Connected_In 



SPEC 



procedure Nodes_Connected_In(Graph ; in out Graph_Typ_Ptr; 

node : in NODE_TYPE; 
in_nodes ; out NODE_COUNT; 
node_connected : out CONNECTED_NODES); 



- Pu^se 

" This procedure will pass out all nodes and the number of nodes connected, 
" to the node passed in, by an in edge. 



Remove_Edge 



SPEC 



procedure Remove_Edge(graph : in out Graph_Typ_Ptr, 

a_node, b_node : in NODE_TYPE); 



-- Pu^se 

- This procedure will remove an edge between the two nodes passed in. 



Remove_Node 



SPEC 



procedure Remove_Node(graph : in out Graph_Typ_Ptr, 

node : in NODE_TYPE); 



-- Pu^se 

-- This procedure will remove the node passed in from the graph and remove all its 
- related edges. 

private 

subtype NODE_COUNT is integer range 0..max_size; 

type CONNECTED_NODES is array (NODE.COUNT) of NODE_TYPE; 

type CONNECTION is (in_edge, out_edge, in_out_edge, not_connected); 

type NODE_STATUS_TYP is 
record 

empty : boolean := true; - Empty node if true. 
node_id : NODE_TYPE; -- User defined data structure, 
end record; 

type NODE_INDEX_ARRAY_TYP is -- One dimensional array containing all nodes, 
array (NODE.COUNT) of NODE_STATUS_TYP; 
type GRAPH_MATRIX_TYP is -- Graph adjacency matrix, 
array (NODE_COUNT, NODE_COUNT) of boolean; 
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type Graph_Typ is 
record 

Number_of_nodes : NODE_COUNT := 0; 

Nodes : NODE_INDEX_ARRAY_TYP; 

Graph_matrix : GRAPH_MATRIX_TYP:= (others =>(others =>true)); 
end record; 

type Graph_Typ_Ptr is access GRAPH_TYP; 

empty_graph : NODE_COUNT ;= 0; -- Node counter for graph. 



end Bounded_Graph; 
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D. UNBOUNDED GRAPH 



* ♦ 

* Unbounded_Graph * SPEC 

♦ ♦ 



generic 

type ELEMENT_TYP is 
private; 

package Unbounded_Graph is 

- PU&POSE: This generic package implements an unbounded directed 
~ graph type. 

- INITIALIZATION EXCEPTIONS: none 

- NOTES: The graph is represented by a set of distinct nodes, 

- with each node having an edge list composed of a set of 

~ distinct nodes. A directed edge exists between a node in the 

- graph and all nodes in it’s respective edge list. 

- MODDFICATIONS: 

- 11/15/91 JX. Budnick Initial build. 

- 05/92 modified by J.M. Sealander. An adjacency node in the original structure pointed to a graph 
-node to identify an adjacent vertex. This pointer was removed and replaced with the node element. Type 
-declarations used to build the data type were moved to the private section. 

type GRAPH_TYP is 
private; 

INPUT_NODE_DOES_NOT_EXIST : exception; 



Is_Empty . SPEC 



function Is_Empty(Graph : GRAPH_TYP) return BOOLEAN; 



- PURPOSE: 

- Returns TRUE if the input Graph is empty, FALSE if it is not 

- EXCEPTIONS: none 

- NOTES: none 

- MODIHCATIONS: 

- 11/15/91 Ji. Budnick Initial build 



Add_Node 



SPEC 



procedure Add_Node(New_Node : in ELEMENT_TYP; Graph : in out GRAPH_TYP); 

- PURPOSE: 

- Adds a New_Node of type ELEMENT_TYP to the input Graph. 

- EXCEPTIONS: none 

- NOTES: 

- If a node is found in the Graph which is a duplicate of 
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- the New_Node, the Graph will remain unaltered. 

- MODIFICATIONS: 

- 11/15/91 JJL. Budnick Initial build 



Remove_node 



SPEC 



procedure Remove_node(Node : in ELEMENT_TYP; Graph : in out GRAPH_TYP); 

- PURPOSE: Removes Node from Graph. 

- EXCEPTIONS: 

- INPUT_NODE_DOES_NOT_EXIST is raised if Node is not found in 

- Graph. 

“ NOTES: All references to Node are removed from Graph, even 
“ references in other Node’s edge lists. 

- MODinCATIONS: 

- 11/15/91 J.L. Budnick Initial build 



Add_Edge 



SPEC 



procedure Add_Edge(From_Node : in ELEMENT_TYP; 

To_Node : in ELEMENT_TYP; 

Graph : in out GRAPH_TYP); 

“ PURPOSE: Adds a directed edge between From_Node and To_Node 
“ within Graph. 

“ EXCEPTIONS: 

- INPUT_NODE_IX)ES_NOT_EXIST is raised if From_Node or To_Node 

- is not found in Graph. 

- NOTES: If To_Node is already an element of From_Node’s edge 

- list, the graph remains unaltered. 

- MODinCATIONS: 

- 11/15/91 J.L. Budnick Initial build 



Remove_Edge 



SPEC 



procedure Remove_edge (From_Node : in ELEMENT_TYP; 

To_Node : in ELEMENT_TYP; 

Graph : in out GRAPH_TYP); 

- PURPOSE: Removes an edge between From_Node and To_Node in the 

- given Graph. 

- EXCEPTIONS: 

- INPUT_NODE_DOES_NOT_EXIST is raised if From_Node is not 

- found in Graph or if To_Node is not found in From_Node’s edge 

- Ust. 

- NOTES: none 

- MODinCATIONS: 

- 11/15/91 Ji. Budnick Initial build 
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Has_An_Edge 



SPEC 



function Has_An_Edge (From_Node : ELEMENT_TYP; 

To_Node : ELEMENT.TYP; 

Graph : GRAPH.TYP) 

return BOOLEAN; 

- PURPOSE: Determines if an edge exists between the two input 
~ nodes of the given Graph. 

- EXCEPTIONS: 

- INPUT_NODE_DOES_NOT_EXIST is raised if From.Node or To_Node 

- is not found in Graph. 

- NOTES: none 

- MODMCATIONS: 

- 11/15/91 JJ-. Budnick Initial buUd 



Set_Of_Outgoing_Edges 



SPEC 



function Set_Of_Outgoing_Edges (From_Node : ELEMENT_TYP; 

Graph : GRAPH.TYP) return NODE_SET_PTR; 

- PURPOSE: Returns the set of edges outgoing from the given 
-- From_Node in Graph. 

- EXCEPTIONS: 

- INPUT_NODE_DOES_NOT_EXIST is raised if From.Node 

- is not found in Graph. 

- NOTES: An outgoing edge set is composed of the set of all 

“ nodes which have directed edges coming from the From_Node to 
-- those in the set. 

- MODmCATIONS: 

- 11/15/91 JJ-. Budnick Initial build 



Set_Of_Incoming_Edges 



SPEC 



function Set_Of_Incoming_Edges (To_Node : ELEMENT_TYP; 

Graph : GRAPH_TYP) return NODE_SET_PTR; 

-- PURPOSE: Returns the set of edges incoming to the given To_Node 
-- in Graph. 

- EXCEPTIONS: 

- INPUT_NODE_DOES_NOT_EXIST is raised if To.Node 

- is not found in Graph. 

- NOTES: An incoming edge set is composed of the set of all 

- nodes which have directed edges from themselves to the 

- To_Node. 

- MODmCATIONS: 

- 11/15/91 JL. Budnick Initial build 
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SPEC 



Set_Of_AU_Nodes 



function Set_Of_AU_Nodes (Graph : GRAPH_TYP) return NODE_SET_PTR; 

~ PURPOSE: Returns the set of all nodes in the input Graph. 

- EXCEPTIONS: none 

- NOTES: The returned node set is simply the complete set of 

- nodes in Graph, and contains no interrelationship data. 

- MOOmCATIONS: 

- 11/15/91 JJ.. Budnick Initial buUd 

private 

type GRAPH_NODE; 
type GRAPH_TYP is 
access GRAPH_NODE; 

type EEKjE; 
type EDGE_PTR is 
access EEH3E; 

type EDGE is 
record 

Edge_node : ELEMENT_TYP; 

Next_Edge : EDGE_PTR := null; 
end record; 

type GRAPH_NODE is 
record 

Element : ELEMENT_TYP; 

Next.Node : GRAPH.TYP := null; 

Edges : EDGE_PTR := null; 
end record; 

EMPTY_GRAPH : constant GRAPH.TYP := null; 
end Unbounded_Graph; 
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E. UNBOUNDED^MAP 

“ Name: Capt Robert M. Dixon 

- Date: 15 Nov 91 

- Modifications : Modified by J. M. Sealander Feb 92. In the orignial version 

- NUM.BINDINGS and NIJM3LOCKS were state variables declared 
-- in the package body. Erroneous data resulted if more than 

~ one variable of MAP_TYPE was declared. They are now part 
of the MAP^TYPE data structure. 

- Course: CS4530 

-- Compiler Verdix Ada 6.0 

- System: Solboume 
“ Tide: Map.Package 

- Remarks: Map_Package implements an unbounded map using a generic Ada package. 

- The package is instantiated with a hash function, which returns an index 

- into the hash table, based on the domain value. If the index lies outside 

- the range of the map, it links in new map blocks until the index falls 

- on a block in the map. 

- The domain/range value is added to the head of a linked list whose head 

- pointer is stored in the map block, at the index pointed to by the hash 

- function. 

- Generic Parameters: DOMAIN_TYPE is the desired type of the domain. 

- RANGE_TYPE is the desired type of the range. 

- Hash is the user’s hashing function. 

- Domain_Put is a put procedure for the domain type. 

- Range_Put is a put procedure for the range tyj)c. 

Domain_Get is a get procedure for the domain type. 

Range_Get is a get procedure for the range type. 

- Granularity specifies how many values will be stored in 

- each block of the hash table. 

generic 

type DOMAIN_TYPE is private; 
type RANGE_TYPE is private; 

with function Hash(Domain_Value : in DOMAIN_TYPE) return NATURAL; 
with procedure Domain_Put(Domain_Value : in DOMAIN_TYPE); 
with procedure Range_Put(Range_Value : in RANGE_TYPE); 
with procedure Domain_Get(Domain_Value : out DOMAIN_TYPE); 
with procedure Range_Get(Range_Value : out RANGE_TYPE); 

Granularity : in INTEGER := 100; 
package Map^Package is 

~ MAP_TYPE is the type that the package user will use to declare a map. 

- MAP_BINDINGS_TYPE is the type used to store the number of bindings in the map. 
~ Add adds a new domain/range pair to the map. 

“ Range_Value returns the range value associated with the domain_value parameter. 

- Is_Bound returns true if the domain_value is in the table. 

- Number_Of_Bindings returns the number of bindings in the map. 

- Remove_Binding removes a domain/range pair from the map. 

- Put prints out the entire map. 

-- Get gets the entire map. 

~ Empty_Map is an empty map constant. 

-» Domain_Exists is raised if a duplicate domain is inserted into the map. 

-- Domain_Not_Found is raised if a domain is not found in the map. 
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type MAP_TTPE is private; 

type MAP_BINDINGS_TYPE is new NATURAL; 



procedure Add(Map : in out MAP_TYPE; Domain_Value ; in DOMAIN_TYPE; 

Range_Value ; in RANGE_TYPE); 

function Range_Value(Map : MAP_TYPE; Domain_Value : DOMAIN_TYPE) 

return RANGE_TYPE; 

function Is_Bound(Map ; MAP_TYPE; Domain_Value : DOMAIN_TYPE) return BOOLEAN; 
function Number_Of_Bindings(Map : MAP_TTPE) return MAP_BINDINGS_TYPE; 
procedure Remove_Binding(Map : in MAP_TYPE; Domain_Value : DOMAIN_TTPE); 
procedure Put(Map ; in MAP_TYPE); 
procedure Get(Map : in out MAP_TYPE); 

Empty_Map : constant MAP_TYPE; 

Domain_Exists : exception; 

Domain_Not_Found : exception; 

private 

type MAP_RECORD_TYPE is 
record 

Domain_Value : DOMAIN_TYPE; 

Range.Value ; RANGE.TYPE; 
end record; 

type MAP_RECORD_NODE_TYPE; 

type MAP_RECORD_NODE_PTR_TYPE is access MAP_RECORD_NODE_TYPE; 
type MAP_RECORD_NODE_TYPE is 
record 

Map_Record : MAP_RECORD_TYPE; 

Next_Node : MAP_RECORD_NODE_PTR_TYPE; 
end record; 

type MAP_ARRAY_TYPE is array(0 .. Granularity - 1) of MAP_RECORD_NODE_PTR_TYPE; 
type MAP_BL0CK_TYPE; 

type MAP_BLOCK_PTR_TYPE is access MAP_BLOCK_TYPE; 
type MAP_BLOCK_TYPE is 
record 

Map.Array : MAP_ARRAY_TYPE; 

Next.Block : MAP_BLOCK_PTR_TYPE; 
end record; 

type MAP_HEAD_TYPE; 

type MAP_TYPE_PTR is access MAP_HEAD_TYPE; 
type MAP_HEAD_TYPE is 
record 

NUM_BINDINGS : MAP_BINDINGS_TYPE ;= 0; 

NUM.BLOCKS : NATURAL :=0; 

HEAD ; MAP_BLOCK_PTR_TYPE; 
end record; 

type MAP_TYPE is new MAP_TYPE_PTR; 

Empty_Map : constant MAP_TYPE ;= new MAP_HEAD_TYPE; 
end Map_Package; 
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F. REAL NUMBERS 



—Author original version : Dogan Ozdemir 
“Author mc^fied version ; J.M. Sealander 

"Original version used separate arrays to hold the whole and decimal part 
-of a real number. Modified version uses one array to hold all the digits 
-and the output is normalized so that the decimal point appears after the 
—first digit 

—Local procedures eliminated from original version: ADD_WHOLE, SUBTRACT_WHOLE, 
-M_SHIFr_LEFT. SHIFT_LEFT, SIMPLIFY, 
with TEXT.IO; 

generic 

DIGIT : INTEGER := 10; 

MAX.EXP : INTEGER := 3; 

package REAL_PKG is 

type REAL is private; 

INPUT.ERROR : EXCEPTION; 



-functions- 



function ADDITION (NUMl JWM2 : REAL) return REAL; 
function “+” (NUMl J>IUM2 : REAL) return REAL renames ADDITION; 



function SUBTRACTION (NMl J'IM2 ; REAL) return REAL; 
function (NMl J'IM2 ; REAL) return REAL renames SUBTRACTION; 



function MULTIPLICATION (NM1JSIM2 : REAL) return REAL; 
function (NMi;'IM2 : REAL) return REAL renames MULTIPLICATION; 



function DIVISION (NMldNfM2 : REAL) return REAL ; 
function "/” (NMl : REAL) return REAL renames DIVISION; 



function EQUAL(N1 :REAL) return BOOLEAN; 



function GREATER (N1J^2 :REAL) return BOOLEAN; 
function “>” (N1J^2 :REAL) return BOOLEAN renames GREATER; 



- This procedure gets a float and converts it to the respective 

- real number. 

function CONV_REAL (FL : FLOAT) return REAL; 



- iwocedures- 



- This procedure reads the Real Number from the screen and 

- decompose it into the sign, digits and exponent 

- arrays. 

procedure GET (NUM : in out REAL ); 



- This procedure puts the real number to the screen 
procedure PUT (R : in REAL); 
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private 



type SIGN is 

subtype DECIMALS is INTEGER range 0 .. 9; 

type MANTISSA_ARRAY is array (I .. DIGIT) of DECIMALS: 

type EXPONENT_ARRAY is array (1 .. MAX_EXP) of DECIMALS; 

type REAL is 
record 

SIGN_WHOLE : SIGN := *+’; 

MANTISSA : MANTISSA_ARRAY := (others => 0); 

SIGN.EXP : SIGN := *+’; 

EXPONENT : EXPONENT.ARRAY := (others => 0); 
end record: 

EMPTY.EXP : constant EXPONENT_ARRAY := (others => 0): 
end REAL_PKG: 
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G. BOUNDED INTEGERS 



*»»«»»*»*»** »**«** *» 4 <* 

-• TITLE : IMPLEMENTATION OF BOUNDED INTEGERS 
-• COURSE : CS 4530 
AUTHOR : Metin Bald 
-* DATE : OCr;i5.91 

— * MODIFICATTONS : Modified by J. M. Sealander Apr 92. Subprogram algorithms simplified. 
-♦ SYSTEM : UNIX 
-* COMPILER : VERDDCADA 
— * FILE : balci/qtr5/cs4530/big_int_spec.a 
— * DESCRIPTION : This generic package contains the specifications 
for implementing the type bounded integer.The 
“* type is implemented as generic big integers with 
— * array representations.The generic parameter is 
DIGIT and it specifies the number of decimal digits 
the represantation support.The generic parameter 
— * is used as value generic parameter and intialized 
to 20 as default value. You can change the generic 
— • value in your implementation(or test)program. 

— * By using “renames” features of ADA, the operations 
"* are overloaded for the normal operators. 

For equality check although a function “equals” is 
supported, user can use “=” operator for this aim. 

This feature is implemented in the test program. 



with TEXTJO; 
use TEXTJO: 

generic 

DIGIT : in INTEGER := 20; 

package BOUNDED_INTEGER_ARRAY_PACKAGE is 



type BOUNDED_INTEGER is private; 



-- for a pven integer it returns a bounded integer,by calling this 

— function we may have operations with both types 

procedure CONVERT (NUM_VAL : in INTEGER ; B_NUM : out BOUNDED.INTEGER); 

— converts the string to a bounded integer type.User is supposed to 

— enter the big integer as a string 

procedure STRING_TO_BOUNDED_INTEGER (STR :in STRING ; LNG:in INTEGER; 

B_INT ;out BOUNDED_INTEGER): 



-- the addition of two bounded integers 

function ADDITION ( B_INT1 :in BOUNDED.INTEGER; 

B_INT2 ;in BOUNDED_INTEGER) return BOUNDED.INTEGER; 



function “+” (B_INT1 tin BOUNDED.INTEGER; B_INT2 tin BOUNDED_INTEGER) 
return BOUNDED_INTEGER renames ADDITION; 



-- subtraction 

function SUBTRACTION (LEFT tin BOUNDED_INTEGER; RIGHTtin BOUNDED.INTEGER) 

return BOUNDED_INTEGER; 

function “-” (LEFT tin BOUNDED.INTEGER; RIGHTtin BOUNDED.INTEGER) 
return BOUT^ED_INTEGER renames SUBTRACTION: 
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“ multiplication 

function MULTIPLICATION (L:in BOUNDED_INTEGER: R;in BOUNDED_INTEGER) 

return BOUNDED_INTEGER ; 

function (L:in BOUNDED.INTEGER; R:in BOUNDED_INTEGER) 

return BOUNDED_INTEGER renames MULTIPLICATION ; 

- division 

function DIVISION (DIVIDENT :in BOUNDED.INTEGER; 

DIVISOR :in BOUNDED_INTEGER) return BOUNDED.INTEGER; 
function ‘T (DIVIDENT :in BOUNDED.DMTEGER; DIVISOR :in BOUNDED.INTEGER) 
return BOUNDED_INTEGER renames DP/ISION ; 



- modulo operation 

function MODULO (FIRST ;in BOUNDED_INTEGER; SECOND :in BOUNDED_INTEGER) 
return BOUNDED_INTEGER; 



function “mod” (FIRST :in BOUNDED_INTEGER; SECOND ;in BOUNDED_INTEGER) return 
BOUNDED_INTEGER renames MODULO; 

- returns if two bounded integer is equal or not 

function EQUALS (LEFTJIIGHT : in BOUNDED_INTEGER )retum BOOLEAN; 



returns if the first entry greater than the second entry 

function GREATER.THAN ( X.Y : in BOUNDED.INTEGER ) return BOOLEAN; 



function “>” ( X.Y : in BOUNDED_INTEGER) return BOOLEAN renames GREATER.THAN; 



- this is the get function which is implemented for test purposes 

procedure GET ( STR_TO_BOUlWED : out BOUNDED_INTEGER); 



“ this is the put function which is implemented for test purposes 

procedure PUT (BOUNDED_TO_STR : in BOUNDED_INTEGER); 



private 

subtype NUM_OF_CHAR is INTEGER range 0..9; 
type SIGN.DIGIT is (‘+’,’-’); 

type B_INT_ARRAY_TYPE is array (NATURAL RANGE 0 .. DIGIT) of NUM_OF_CHAR; 
type BOUNDED_INTEGER is 
record 

SIGN: SIGN.DIGIT ; 

B_INT_ ARRAY : B_INT_ARRAY_TYPE; 
end record; 

end BOUNDED_INTEGER_ARRAY_PACKAGE; 
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H. VECTORS 



--Title : Vector ADT 
-Author : Jennie M. Sealander 
-Date : 14 November 1991 
-Course : CS^530 
-Compiler : Verdix Ada 

-Description: Generic package for Abstract Data TVpe Vector. 



* VECTORS * SPEC 

with TEXT_10; use TEXT_IO; 
generic 

type ELEMENT_TYPE is private; -vector component type, must be a 
-numeric type 

DIMENSION ; in POSITIVE; -dimension of vector type 
with function “+” (X.Y: ELEMENT_TYPE) return ELEMENT_TYPE; 
— Fhi^se 

-This function defines addition for the numeric ELEMENT_TYPE 

with function (X.Y; ELEMENT.TYPE) return ELEMENT_TYPE; 
-Pu^se 

-This function defines subtraction for the numeric ELEMENT_TYPE 

with funcUon (X.Y: ELEMENT.TYPE) return ELEMENT.TYPE; 
-Pu^se 

-This function defines multiplication for the numeric ELEMENT_TYPE 

with function ZERO return ELEMENT_TYPE; 

-Pu^se 

“This function defines zero for the numeric ELEMENT_TYPE 

with function SQRT(X; ELEMENT_TYPE) return ELEMENT_TYPE; 
“Pu^se 

“This function defines the square root for ELEMENT_TYPE 

with procedure PUT(X: ELEMENT_TYPE); 

“Pu^se 

“This procedure defines PUT for the numeric ELEMENT_TYPE 

with procedure GET(X: out ELEMENT_TYPE); 

“Pu^se 

“This procedure defines GET for the numeric ELEMENT_TYPE 
package VECTORS is 

type VECTOR is array(l..DIMENSION) of ELEMENT.TYPE; 

function “+” (V1.V2 ; in VECTOR) return VECTOR; 

“Purpose 
-Vector addition 
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function (V1.V2 : in VECTOR) return VECTOR; 

--Purpose 

-Vector Subtraction 

function (VI : in VECTOR; S: in ELEMENT.TYPE) return VECTOR; 
-Purpose 

-Multiplication of a vector by a scalar 

function (V1.V2 : in VECTOR) return ELEMENT_TYPE; 

-Purpose 

—Vector Dot Product, multiplication of two vectors 

function LENGTH (V : in VECTOR) return ELEMENT_TYPE; 

-Purpose 

-Returns magnitude of vector 

procedure PUT_ VECTOR (V: VECTOR); 

-Purpose 

-Ou^uts an object of type VECTOR 

procedure GET_ VECTOR (V: out VECTOR); 

-Purpose 

-Gets an object of type VECTOR 



INPUT_ERROR : exception; 

-Pu^se 

—Raised if error in input of type VECTOR 
end VECTORS; 
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I. MATRIX 



-Title ; Generic Matrix Package 
-Author : William C. Hoppe 
-Date : 7 November 1991 
-Revised ; 

-Course : CS4530 

-System : SUN-3 UNIX 

-Compiler : Verdix Ada, VADS, Ver 6.0 

-Description : Generic Package to implement the Abstract Data Type (ADT) 

— Matrix, and operations: conversion from an array to a 

- matrix, matrix addidon and subtraction, multiplicadon 

- by a scalar (value of the element_type), matrix 

— muldpIicaUon, and transpose. 



generic 

type ROW.LENGTH is (o); 
type COLUMN.LENGTH is (<>); 
type ITEM is private; 

with funcdon “+” (X, Y : in ITEM) return ITEM is o; 
with funcdon (X, Y : in ITEM) return ITEM is <>; 

with funcdon (X, Y : in ITEN^ return ITEM is <>; 

package Matrix is 



type ARRAY_TYPE is anay(ROW_LENGTH range o, COLUMN_LENGTH range o) of ITEM; 

type MATRIX.TYPE is array(ROW_LENGTH range o, COLUMN.LENGTH range o) of ITEM; 

type TRANSPOSE_MATRIX_TYPE is array(COLUMN_LENGTH range o, 

ROW_LENGTH range o) of ITEM; 



NON_CONFORMABLE_FOR_ADDmON_ERROR : excepdon; 
NON_CONFORMABLE_FOR_MULTIPLICATION_ERROR : excepdon; 

funcdon Convert_to_Matrix (Numerical_Airay : ARRAY_TYPE) return MATRIX_TYPE; 

funcdon Matrix_Add (Matrix I, Matrix2 : in MATRIX_TYPE) return MATRIX_TYPE; 

funcdon Matrix_Subtract (Matrix 1, Matrix2 : in MATRIX_TYPE) return MATRIX_TYPE; 

funcdon Matrix_Muldply (Scalar : in ITEM; Matrix : in MATRIX_TYPE) return MATRIX_TYPE; 

funcdon Matrix_Muldply (Matrix 1, Matrix2 : in MATRIX_TYPE; 

Initial_Value : in ITEM ) return MATRIX_TYPE; 

funcdon Transpose (Matrix : in MATRIX_TYPE) return TRANSPOSE_MATRIX_TYPE; 
end Matrix; 
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APPENDIX B. KODIAK PROGRAM LISTING 



.'definition of lexical classes 



%define Digit 
%define Int 
%define Lower 
%define Upper 
%define Letter 
%define Alpha 
%define Underscore 
%define Blank 
%define Quote 
%define Backslash 
%define Char 



[ 0 - 9 ] 

{ Digit) + 

[a-z] 

[A-Z] 

({Lower) I (Upper)) 

({Letter)l(Digit)) 

[“_’T 

['t\n] 

[“] 

A\” 

([^’\\]l (Backslash) {Quote)l(Backslash) (Backslash)) 



Idefinition of white space comments 

;{Blank)+ 

;”-”.*’Nn” 



! definitions of compound symbols and keywords 



PACKAGE 

IS 

PRIVATE 

END 

USE 

TYPE 

PROCEDURE 

FUNCTION 

RETURN 

IN 

OUT 

TASK 

ENTRY 

EXCEPTION 

RENAMES 

CONSTANT 

SUBTYPE 

NEW 

RANGE 

GENERIC 

WITH 

DIGITS 

DELTA 

LIMITED 

FOR 

AT 

ALL 

CASE 

WHEN 

OTHERS 

ACCESS 

Al^ 

THEN 

OR 

ELSE 

NOT 



; packagelPAC KAG E 
:islIS 

:privatelPRIVATE 

rendEND 

:uselUSE 

rtypelTYPE 

rprocedurelPROCEDURE 

:functionlFUNCTION 

:retumlRETURN 

:inlIN 

:outlOUT 

:tasklTASK 

;entrylENTRY 

:exceptionEXCEPTION 

:renameslRENAMES 

xonstantICONSTANTI”” 

rsubtypelSUBTYPE 

;newlI^W 

:rangelRANGE 

igenericlGENERIC 

:withlWITH 

rdigitsIDIGITS 

:deltalDELTA 

rlimitedlLIMITED 

:forEOR 

ratlAT 

talllALL 

:caselCASE 

:whenlWHEN 

:otherslOTHERS 

:accesslACCESS 

:”&’T’and’T’AND” 

:thenlTHEN 

:’T’l”or”rOR” 

:elselELSE 

motINOT 
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XOR 

ABS 

NULL 

EQUAL 

NEQ 

LT 

LTE 

GTE 

GT 

PLUS 

MINUS 

TIMES 

DIVIDE 

EXPONENT 

MOD 

REM 

ARRAY 

OF 

RECORD 

DISCRETE 

ARROW 

TO 

TIC 

CHARACTER_LITERAL 

STRING_LITERAL 

INTEGER_LITERAL 

REA L_LITE RAL 

IDENTIFIER 



xorIXOR 

abslABS 

nulllNULL 




» »» 



T 

modlMOD 

remlREM 

arraylARRAY 

oflOF 

recordIRECORD 

”<>” 

»» 



(Quote) (Char)* (Quote) 

(Int) 

(Int)”.”(Int) 

{ Letter ) +(( (Underscore ) I Alpha)* ( Alpha ) )* 



%% 

! Explanations of attributes 

!psdl_interface_specification : synthesized string, the result of the 
! translation 

!operator_specification : synthesized string, builds the operator specification 
! for psdl types 

!number_of_operators : synthesized integer, counts the number of operators 
! in ada specification to determine if psdl interface 

! is a type or single operator 

!new_composite_types : synthesized map, used to build the inherited map, 

! composite_types 

!composite_types : inherited map, used to determine if a generic declaration 
! is part of a composite type declaration, i.e. an array type 

!new_generic_types : synthesized map, used to build the inherited map, 

! generic_types 

!generic_types ; inherited map, provides the type names of the 
! index and element types for a generic array type 

!generic_type_declarations ; synthesized string, builds the generic type 
! declaration portion of psdl then inherited 

! by package_specification 

!type_declarations : synthesized string, builds the non-generic type 
! declaration pc»tion of p^ 
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!input_parameters : synthesized string, builds the input attribute of a psdl 
! operator 

!ouiput_parameters : synthesized string, builds the output attribute of a psdl 
! operator 

Imode: synthesized map, used to determine if there are any input out output 
! parameters to an operator specification 

!mode_check: inherited map, initializes attribute mode to default of empty 
1 string 

!current_mode: synthesized string, used to determine if a comma is required 
! between two parameters 

! exceptions : synthesized string, provides exceptions declared in a single 
! operator package 

!variable_name : synthesized string, provides the name of an input or output 
! parameter 

!variable_type : synthesized string, provides the type name for variables 
! declared in the generic portion and type declaration of the 

! PSDL specification 

[attribute declarations for nonterminal symbols 

stari{ psdl_interface_specification:string; ); 

ada_interface{ psdl_interface_specification:string; 
file_name:string; }; 

generic_specification { psdl_interface_specification:string; 
generic_type_declarations:string; 
file_name:string; }; 

generic_fonnal_part{ generic_type_declarations:string; }; 

generic_parameter_declarations{generic_type_declarations:string; 
new_composite_typ^:string->string; 
composite_types:string->string; 
new_generic_typ^:string->string; 
generic_types:string->string; 
commarstring; }; 

generic_parameter_declaration { generic_type_declarations:string; 
new_composite_types:string->string; 
composite_types:string->string; 
new_generic_typ^:string->string; 
generic_types:string->string; 
commaistring; }; 

generic_type_definition { variable_type:string; 

generic_types: string->string; 
new_composite_types:string->string; ); 

private_type_declaration { generic_type_declarations:string; 
type_decl^tions:string; ); 

package_specification { psdl_interface_specification:string; 
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number_of_operators: int; 
generic_type_declarations:slring; 
file_name:string; }; 

basic_declarati ve Jteins { type_declarations:string; 

operator__specification:string; 
number_oLoperators: int; 
inpuLparametersrstring; 
output_parameters:string; 
exceptionsrslring; }; 

basic_declarative_iteni{ type_declarations:string; 

operator_specification:string; 
input_parameters:string; 
output jarametersrslring; 
exceptionsrstring; 
number__of_operators:int; }; 

basic_declaration{ type_declarations:slring; 
operator_specification:string; 
input_parameters:string; 
output_parameters:string; 
exceptionsrstring; 
number_of_operators:int; }; 

subprogram_declaration ( operator_specification:string; 
input_parameters:string; 
output_parameters:string; 
number__of_operators:int; 
exceptionsrstring; }; 

subprogram_specificalion { operalor_specificationrstring; 
inputjarametersr string; 
outpuLparametersrstring; 
number_of_operatorsrint; 
namerstring; }; 

formal_part{ input_parametersrstring; 
outpuLparametersrstring; ); 

designator{ namerstring; 

operator__symbolsrstring->string; }; 

operator_symbol{ namerstring; ); 

parameter_specifications{ input__parametersrstring; 
ouq)ut_paiametersrstring; 
moderstring->string; 
mode_chedcrstring->siring; 
current^moderstring; } ; 

parameter_specification{ input_parametersrstring; 
output_parametersrstring; 
modersiring->string; 
mode_checkrstring->string; 
current_moderstring; }; 

type_declarations{ type_declarationsrstring; ); 

type_declaration{ type.declarationsrsiring; }; 
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full_type_declaration{ type_declarations:string; ); 

exception_declaration { exceptionsrstring; }; 

subtype_declaration { type_declarations:string; ); 

generic_declaration{ type_declaraiions:string; }; 

subtype_indication { variable_type:siring; 

generic_types:string->string; 
new_composite_types:string->string; 
element_type:string; ); 

type_definition{ variable_type:siring; }; 

real_type_definition { variable_type:string; }; 

array_type_definition { variable_type:string; 

generic_types: stri ng-> string; 
new_composite_types:string->string; ) ; 

unconstrained_array_definition { variable_type:string; 

generic_types:string->string; 
new_coinposite_types:string->string; ) ; 

constrained_array_definition { variable_type: string; 

generic_types:string->string; 
new_composite_types:string->string; }; 

subtype_definitions { generic_types:string->slring; 

new_composite_types:string->siring; 
index_type:string; ); 

index_subtype_definition { generic_types:string->string; 
index_type:string; 

new_composite_types:string->string; }; 

identifierjist{ variable_names:string; 
exceptionsrstring; ); 

type_mark{ variable_type:string; ); 

name { variable_type:string; 
variable_name:string; 
generic_types:string->string; 
new_composite_types:string->string; 
index_type:siring; 
element_type:string; ); 



lattribute declarations for terminal symbols 

IDENTIFIER { %text:string; }; 
STRING_LnERAL{ %text:string; ); 



%% 

! Productions of the grammar 
start 

: ada_interface 

{ %output(ada_interface.psdl_inierface_specification); 
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%outfile(ada_interface.file_name, 

ada_interface.psdl_interface_specification); ) 



ada_interface 

: context_clause generic_specification 

{ ada_interface.psdl_interface_specificaiion = 

generic_specification.psdl_interface_specificalion; 
ada_interface.file_name = 
generic_specification.file_name; ) 

I context_clause package_specification 

{ ada_interface.psdl_interface_specificaiion = 

package_specification.psdl_interface_specification; 
ada_imerface.file_name = 
package_sp)ecification.file_name; ) 



context_cIause 

: with_clauses use^clauses 

{) 

I 

{) 



with_clauses 

: with_clauses with_clause 

{) 

I with_clause 

{) 



use_clauses 

: use_clauses use_clause 

{) 

I 

{) 



with_clause 

: WITH package_names 

{) 



use_clause 

: USE package_names 

{} 



package_names 

: package_names name 

{} 

I name 



{} 



generic_specification 

; generic_formal_part subprogram_specification 

{ } 

I generic_formal_i^ package_specificadon 

{package_specification.generic_type_declarations = 
generic_formal_part.generic_type_declarations; 
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generic_specification.psdl_interface_specification = 
package_specification.psdl_interface_specification; 
generic_specification.file_name = 
package_specification.file_nanie; } 



generic_fonnalj3art 

: GENERIC generic_parameter_declarations 

{ generic_fonnal_part.generic_type_declarations = 

[“ GENERICNn”. 

generic_parameier_declarations.generic_type_declarations, 

generic_parameter_declarations.generic_types = 
generic_paraineter_declarations.new_generic_types 
+1 {(?:string:”INDEX_TYPE”)}; 
generic_parameter_declarations.composite_typ^ = 
generic_parameter_declarations.new_composite_types 
+1 ((?:string:W)); } 

I 

{} 



generic_par^eter_declarations 

: generic_parameter_declarauons generic_parameter_declaration 
{ generic_parameter_declarations[l].generic_type_declarations = 
generic_parameter_declarations[2] .comma == 

-> [generic_parameter_declarations[2] .generic_type_declarations, 
“.Nn”, 

generic_parameter_declaration.generic_type_declarations] 

# [generic_parameter_declarations[2] .generic_type_declarations, 
generic_parameter_declaration .generic_type_declarations] ; 
generic_parameter_declarations [ 1 ] .ne w_generic_types = 
[generic_parameter_declarations[2] .new_generic_types +1 
generic_parameter_declaration.new_generic_types]; 
generic_parameter_declaration.generic_types = 
generic_parameter_declarations.generic_types; 
generic_parameter_declarations[2].generic_types = 
generic_parameter_declarations[ 1 ] .generic_types; 
generic_parameter_declarations[ 1 ] .new_composite_types = 
generic_parameter_declarations[2].new_composiie_types 
+1 generic_parameter_declaration.new_composite_types; 
generic_parameter_declaration.composite_types = 
generic_parameter_declarations.composite_types; 
generic_parameter_declarations[2] xomposite_types = 
generic_parameter_declarations[ 1 ] .composite_types; 
generic_parameter_declarations[l]. comma = 
generic_parameter_declaration.comma; } 

I generic_parameter_declaration 

{ generic_parameter_declarations.generic_type_declarations = 
generic_parameter_declaration.generic_type_declarations; 
generic_parametCT_declaration.generic_types = 
generic_parameter_declarations.generic_types; 
generic_parameter_declaration.composite_types = 
generic_parameter_declarations.composite_types; 
generic_parameter_declarations.new_composite_types = 
generic_parameter_declaration.new_composite_types; 
generic_parameter_declarations.new_generic_types = 
generic_parameier_declaration.new_generic_types; 
generic_parameter_declarations.comma = 
generic_parameter_declaration.comma; ) 
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generic_parameter_declaration 
: identifier_list type_mark 

{ generic_parameter_declara tion. generic_type_dec larations = 

[“ “,identifier_listoVariable_naincs,”: GENERIC_VALUE”] ; 
generic_parameter_declaration.new_composite_types = 
generic_parameter_declaration.new _generic_types = 
generic jarameter_declaration.connma = } 

lidentifier_list IN type_mark 

{ generic_parameter_declaradon.generic_type_dec larations = 

[“ “,identifier_list.variable_names;’:GENERIC_VALUE”]; 
generic_paranieter_declaration.new_composite_types = 
generic_parameter_declaration.new_generic_types = 
generic_parameter_declaration.comma = “yes”; } 

I identifierjist IN OUT type_mark 

{ generic_parameter_declaration.generic_type_declarations = 

[“ identifier Jst.variable_names,”:GENERIC^VALUE”]; 

generic_parameter_declaration.new_composite_types = 
generic_parameter_declaration.new_generic_types = 
generic_parameter_declaration.comma = “yes”; } 

I identifierjist type_mark EQUAL expression 

{ generic_parameter_declaration.generic jype_declarations = 

[“ “,identifier_list. variable_names,”: GENERIC_VALUE”] ; 
generic_parameter_declaration.new_composite_types = 
generic_parameter_declaration.new_generic_types = ““; 
generic_parameter_declarationxonnma = “yes”; } 

I identifierjist *:* IN type_mark EQUAL expression 

{ generic_parameter_declaration.generic jype_declarations = 

[“ “,identifier^list.variablejames”:GENERIC^VALUE”]; 
generic_parameter_declaration.new_composite_types = ““; 
generic_parameter_declaration.new_generic_types = ““; 
generic_parameter_declaration.comma = “yes”; } 

I identifierjist IN OUT type_mark EQUAL expression 
{ generic_parameter_declaration.genericjype_dec larations = 

[“ “,identifier_list.variable_names”:GENERIC_VALUE”]; 
generic_parameter_declaration.new_composite_types = ““; 
generic_parameter_declaration.new_generic jypes = ““; 
generic_parameter_declaration.comma = “yes”; } 

I TYPE IDENTIFIER IS PRIVATE 

{ generic_parameter_declaration.generic jype_declarations = 
generic_paianieter_declaration.compositejypes(IDENTIFIER.%text) 



generic_parameter_declaration.new_generic_types = 

{ (IDENTIFIER.%texi:”PRI VATE”) } ; 
generic_parameter_declaration.new_composite_types = 
generic_paranieter_declaration.comnia = 

generic_parameter_declaration.conipositejypes(IDENTIFIER.%text) 

= “yes” 

-> “no” 

#“yes’*;} 

I TYPE IDENTIFIER IS discriniinant_part PRIVATE 

{ generic_parameter_declaration.genericjype__dec larations = 
generic_parameter_declaration.compositeJypes(IDENTIFl£R.%text) == “yes” 



= yes 



# [“ “,IDENTIFIER.%text ” ; GENERIC_TYPE”]; 




generic_parameter_declaration.new_composite_types = ““; 
generic_parameter_declaration.comma = 
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generic_paraineier_declaration.composite_types(IDENnFIER.%text) 
= “yes” 

-> “no” 

#“yes”;J 

I TYPE IDENTIFIER IS LIMITED PRIVATE 

{generic_parameter_declaration.generic_type_declarations = 
generic_parameter_declaration.composite_types(IDENTlFIER.%text) 
= “yes” 

.> 

#[“ “aDENTIFIER.%iext,” : GENERIC.TYPE”]; 
generic_ parame tcr_declaratJon,new_generic_types = 
{(IDENTIFIER.%text: "PRIVATE”)} ; 
generic_parameter_declaration.new_composite_types = 
generic_parameter_declaration.comma = 

generic_parameter_declaration.composite_types(IDENTTFrER.%text) 
= “yes” 

-> “no” 

# “yes”; ) 

I TYPE IDENTIFIER discriminant_part IS LIMITED PRIVATE 
(generic_parameter_declaration.generic_type_declarali ons = 
generic_parameter_declarauon.composite_types(IDENnFIER.%text) 

— tt T> 



#[“ “4DENTIFffiR.%text,” : GENERIC.TYPE”]; 
generic_parameter_declaralion.new_generic_types = 

{ (IDENTIFIER.%text:’TRI VATE”) ) ; 
generic_parameter_declaration.new_composite_types = 
generic_parameter_declaration.comma = 

generic_parameter_declaration.composite_types(IDENTIFIER.%text) 



#“yes”;) 

I TYPE IDENTIFIER IS generic_type_definition 

{generic_parameter_declaration.generic_type_declarations = 
generic_paranieter_declaration.composite_types(IDENTIFIER.%text) 
= “yes” 



#[“ “JDENTIFIER.%texC’ : “, 
generic_type_definition.variable_type]; 
generic_type_definition.generic_types = 
generic_parameter_declaration.generic_t^s; 
generic_parameter_declaration .new_generic_types = 
{(IDENTIFIER.%text:”DISCRETE”)); 
generic_parameter_declaration.new_composite_types = 
generic_type_definition.new_composite_types; 
generic_parameter_declaration.comma = 

generic_parameter_declaration.com posite_types(IDENTIFrER.%text) 
= “yes” 

-> “no” 

# “yes”;) 

I WITH subprogram_specification 

{ generic_parameter_declaration.generic_type_declarations = 

[“ “,subprogram_specification.name,”: GENERIC_PROCEDURE”]; 
generic_parameter_declaration.new_composite_types = 
generic_parameler_declaration.new_generic_types = ““; 
generic_parameter_declaration.comma = “yes”; ) 

I WITH subprogram_specification IS name 

{ generic_parameter_declaration.generic_type_declarations = 

[“ “^ubprogram_specification.name,”; GENERIC_PROCEDURE”j; 
generic_parameter_declaration.new_composite_types = ““; 
generic_parameter_declaration.new_generic_types = 
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generic_pararneter_declaration.comma = “yes”; } 

1 WITH subprogram_specification IS DISCRETE 

{ generic_j)arameter_declaration.generic_type_declarations = 

[“ “,subprogram_specification.name,”: GENERIC_PROCEDURE”]; 
generic_parameter_declaration.new_composite_types = 
generic_parameter_declaration.new_generic_types = 
generic_parameter_declarationxomma = “yes”; } 



package_specification 

: PACKAGE IDENTIFIER IS basic_declarative_items END IDENTIFIER 
{ package_specificadon.psdl_interface_specification = 
basic_declarative_items.number_of_operators == 1 
-> [“OPERATOR ‘MDENTIFIER.%text,’^nSPECIHCATION^n’^ 
package_specification .generic_type_declara tions ,’^n ”, 
basic_declarative_items.inpuLparaineters, 
basic_decla^ativeJtems.output_pa^amete^s,’^n”, 
basic_declarative_items.exceptions, 

“ENDNn’l 

# [“TYPE “4DENTIFIER.%text,’^nSPECI^CATION^n”, 

package_specification.generic_type_decla^ations,’^n”, 

basic_declarativeJtems.type_declarations, 

basic_declarative_items.operator_specification, 

“ENDNn’l; 

package_specification.file_name = [IDEN lIFlER.%text, “.psdl”]; } 

I PACKAGE IDENTIFIER IS basic_declarative_i terns PRIVATE 
basic_declaradvej terns END IDENTIFIER 
{ package_specificadon»psdl_interface_specificadon = 
basic_declaradve_items.number_of_operators == 1 
-> [“OPERATOR “,roENTIFIER.%text,’’SnSPECinCATIONNn”, 
package_specificadon.generic_type_declaradons,’Nn”, 
basic_declaradve_items.input_parameters, 
basic_declaradveJtems.output_paranieters, 
basic_declaradveJtems.excepdons, 

“ENDVn”] 

# [“TYPE “ JDENTIFTER.%text,’^nSPECI^CATION^Jl”, 

package_specificadon.generic_type_declaradons,”Sn”, 

basic_declaradveJtems.type_declaradons, 

basic_declaradve_items.operator_specificadon, 

“ENDVl; 

package_specificadon.file_name = [IDENllHER.%text, “.psdl”]; } 



basic_declaradve_items 

: basic_declaradve_items basic_declaradve_item 
( basic_declaradveJtems[l].type_declaradons = 

[ basic_declaradveJtems[2].type_declaradons, 
basic_declaradve_item .typc_declaradons] ; 
basic_declaradve_items[ 1 ] .operator_specificadon = 
[basic_declaradve_items[2].operator_specificadon, 
‘^n”,basic_decIa^adveJtem .operator_specificadon] ; 
basic_declarad ve_items[ 1 ] .input_parameters = 
[basic_declaradve_items[2]jnput_parameters, 
basic_declarad vejtem .input_parameters] ; 
basic_declaradve_items[l].output_parameters = 

[ basic.declarad ve Jtems[2] .ouiput_parameters, 
basic_dec laradve Jtem .outpu t__parameters] ; 
basic_declaradve_items[l]. exceptions = 

[ basic_declaradve_items[2] .exceptions, 
basic_dec larati ve_item .exceptions] ; 
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basic_declaraiive Jtems[ 1 ] .number_of_operators = 

basic_declarative_items[2] .number_of_operators + * 
basic_declarative Jtem .number_of_operators; } 

{ basic_declarative Jtems.type_declaraiions = 
basic_declarauveJtems.operator_specificaiion = 
basic_declarative_items.number_of_operators = 0; 
basic_declarativejtems.input_parameters = 
basic_declarauveJtems.output_parameters = 
basic_declarative_items.exceptions = ) 



basic_declarative_item 
: basic_declaraiion 

{ basic_declarative_item.typc_declarations = 
basic_declaraiion.type_declaraiions; 
basic_declarative_item.operator_specificaiion = 
basic_declaration.operator_specification; 
basic_declarauve_item.input_parameters = 
basic_declaraiion.input_parameters; 
basic_declarauve_item.output__paraineters = 
basic_declaration.output_parameters; 
basic^declarativejtem.exceptions = 
basic_declaration.exceptions; 
basic_declarauveJtem.number_of_operators = 
basic_declaration.number_of_operators; } 

I representation_clause 

{} 

I use_clause 

{) 



basic_declaration 

: object_declaration 

{ basic_declaration.number_of_operators = 0; 
basic_declaration.type_dedarations = 
basic_declaration.operator_specification = } 

I type_declaiation 

{ basic_declaration.type_declarations = 
type_declaration.t^_declarations; 
basic_decIaration.operator_specification = 
basic_deciaration.number_of_operators = 0; } 

I subprogram_declaration 

{ basic_declaraiion.type_declaradons = 
basic_deciaration.operator_specification = 
subprograni_declaration.operator_specification; 
basic_dedaration.inpui_parameters = 
subprogram_declaration.input_parameiers; 
basic_decIaration.output_parameters = 
subprogram_declaration.output_paranieters; 
basic_declaration.exceptions = 
basic_declaration.number_of_operatoi:s = 
subprograin_declaration.numb«r_of_operators+ 1; } 

I task_declaration 

{) 

I exception_declaration 

{basic_declaration.exceptions = exception_declaration.exceptions; 
basic_declaration.type_declarations = 
basic_declaration.input_parameters = 
basic_declaration.output_parameters = 
basic_declarauon.operaior_specification = 



71 



basic_declaration.number_of_operators = 0; } 

I renaming_declaration 

{basic_declaration.type_declarations = 
basic_declaration.operator_specification = 
basic_declaration.number_of_operators = 0; } 

I subtype_declaration 

{basic_declaradon.type__declarations = 
sub^^_declaration.type_declaratioiis; 
basic_declaration.operator_specification = 
basic_decIaration.number_of_operators = 0; } 
I generic_declaration 

{basic_declaradon.type_declarations = 
basic_declaradon.operator_specification = 
basic_declaradon.number_of_operators = 0; } 



represenladon_clause 

: type_represenladon_clause 

{} 

I address_clause 

{} 



lype_representadon_clause 

; enumeradon_representadon_clause 

{) 

1 length_clause 

{) 

I record_representation_clause 

{} 



oHHf'Pcc pIqiic/* 

: FOR IDENTIFrER USE AT simple.expression 

{} 



enumeration_representation_clause 

: FOR IDENTIFIER USE aggregate 

{} 



length_clause 

: FOR attribute USE simpIe_expression 

{) 



record_represent ation_c lausc 

; FOR IDEN l lFIER USE RECORD alignment_clauses component_clauses 

END RECORD*:’ 



{) 



alignment_clauses 

: alignment_clauses alignment_clause 

{) 

I 

{) 



alignment_clause 
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: AT MOD simple^expression 

{) 



component_clauses 

: component_clauses component_clause 

{) 

I 

{} 



component_clause 

: name AT simple_expression RANGE range 



object_declaration 

; identifier_list subtypejndication 

{) 

I identifierjist constrained_array_definition 

{) 

I identifierjist CONSTANT subtypejndication 

{) 

I identifierjist CONSTANT constrained_array_definition 

{) 

I identifierjist subtype_indication EQUAL expression 

{) 

I identifierjist CONSTAOT subtypejndication EQUAL expression 

{) 

I identifierjist constrained_airay_definition EQUAL expression 

{) 

I identifierjist constrained_array_definition EQUAL expression 

{) 

I IDENTIFIER subtypejndication 

{) 

I IDENTIFIER constrained_array_definition 

{) 

I IDENTIFIER CONSTANT subtypejndication 

{) 

I IDENTIFIER CONSTANT constrained_airay_definition 

{} 

I IDENTIFIER subtype_indication EQUAL expression 

{) 

I IDENTIFIER CONSTANT subtype_indication EQUAL expression 

{) 

I IDENTIFIER constrained_array_definition EQUAL expression 

{) 

I IDENTIFIER constrained_array_definition EQUAL expression 

{) 



type_decIaration 

: full_type_declaration 
{ type_declaration.type_decIarations = } 

I incomplete jype_declaration 
{ type_declaration.type_declarations = } 

I private_type_declaration 
{ type_declaration.type_declarations = 
private_type_declaration.type_declarations; ) 
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subprogTain_declaration 

: subprogram_specification 
( subprogram_declaration.operator_specification = 
subprogiam_specification.operator_specification; 
subprogram_declaration.input_paraineters = 
subprogram_specification.input_parameters; 
subprograni_declaration.output_parameters = 
subprogram_specification.output_parameters; 
subprogxain_declaration.number_of_operators = 0; } 



task_declaration 

: task_specification 

{) 



exception_declaration 

: IDENTIFIER EXCEPTION 
{exception_declaration.exceptions = 

[“ exception : ‘MDENTIFIER.%text, } 

I identifierjist EXCEPTION 
{exception_declaration.exceptions = 

[“ exception : “,identifier_listexceptions, ‘^n”]; ) 



renaming_ declarat ion 

: IDENTIFIER type_mark RENAMES name 

{) 

I IDENTIFIER EXCEPTION RENAMES name 

{} 

I PACKAGE IDENTIFIER RENAMES name 

{} 

I subprogram_specification RENAMES name 

{} 



subtype_decIaration 

: SUBTYPE IDENTIFIER IS subtypejndication 
{ subtype_declaration.type_declarations = ) 



generic_declaration 

: generic_specification 



fulI_type_decIaration 

: TYPE IDENTIFIER discriminant_part IS type_definition 

{} 



incomplete_type_declaration 

: TYPE IDENTIFIER discriminant_part 

{) 



discriminantj)art 

: ‘(‘ discriminant_specifications *)’ 

{} 

I 

0 



74 



discriminam_specifications 

: discriminant_specifications discriminant_specifi cation 

(1 

I discriminant_specification 

{) 



discriminant_specification 

: identifier_list type_mark 

{] 

I identifier Jist type_mark EQUAL expression 

{] 

» 

type_definition 

: enumeration_type_definition 

{) 

I real_type_definition 

{) 

I record_type_definition 

{) 

I derived_type_definition 

{) 

I integer_type_definition 

I array_type_definition 

{) 

I access_type_definition 

{) 



subprogram_specification 

; PROCEDURE IDENTIFIER formaI_part 

{ subprogram_specificadon.operator_specification = 

[“ OPERATOR “,IDENTIFIER.%text,”Vn SPECfflCATIONNn”, 
formal _part.input_parameters, 
fonnal_part.output_parameters,” ENDNn” ]; 
subprogram_specification.input_parameters = 
[formal_part.input_parameiers] ; 
subprogram_specification.output_parameters = 
[formal_part.output_parameters] ; 
subprogram_specification.name = IDENTIFIER.%text; ) 

I FUNCTION designator formal_part RETURN tj^_mark 
( subprogram_specificadon.operator_specification = 

[“ OPERATOR “,designator.name,”Vn SPECMCATIOMNn”, 
fonnal_parLinput_parameters, 

“ output “.designator.name,” : 

type_mark.variable_type,”Vn END^n” ]; 
subprogram_specification.name = designator.name; 
subprogram_specification.input_parameters = 
[formal_part.input_parameters]; 
subprogram_specification.output_parameters = 

[“ output “.designator.name,” : 
type_mark.variable_type]; j 



designator 

: IDENTIFIER 

■ { designatonname = IDENTlFl£R.%text; } 
I STRING.LITERAL 
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{ designalor.operator_symbols = ((‘V+\””:”add”) 
CV-V”:”subtracO (‘V^\””:”multiply”) (‘VA””:”divide”) 
CV=V’”:”equal”) (‘V<\””:”less_than”) (‘\’>V’”:”greater_ihan”) 
(‘V<=V’”:’’LTE”) C\”>=V’”:”GTE”) 
(?:string:”overloaded_operator”)} ; 
designatorname = 

designator.operator_symbols(STRING_LITERAL.%text); } 



formal_part 

: ‘(‘ parameter_specificadons *)’ 

{ parameter_specifications.mode_check = {(?:string:””)}; 
formal_part.input_parpieters = 

parameter_si>ecifications.mode(“input__parameter”) == “yes” 
-> [“ input “,parameter_specifications.input_parameters, 

# 

formal_parl.output_paranieters = 

parameter_specifications.mode(“output_parameter”) == “yes” 
-> [“ output “,parameter_specifications.output_parameters, 
‘^n”] 

# } 

I 

{ formal_partinput_parameters = ““; 
formal_part.output_paranieters = } 



parameter_specifications 

: parameter_specifications parameter_specification 
{ parameter_specifications[l].input_parameters = 
((parameter_specification.cuiTent_mode = “in”) li 
(parameter_specification.current_mode = “inout”)) && 
((paraineter_specifications[2].cunent_mode == “in”) II 
(parameter_specifications[2].current_mode == “inout”)) 
->[parameter_specifications[2].input_parameters, 

“, “,parameter_specification.input_parameters] 

# [parameter_specifications[2] .input__parameters, 

parameter_specification.input_parameters]; 
parame ter_specifications[ 1 ] .output_parameters = 
((parameter_specification.current_mode = “out”) II 
(paranieter_specification.current_mode = “inout”)) && 
((parameter_specifications[2].cunent_mode == “out”) II 
(parameter_specifications[2].current_mode == “inout”)) 
->[parameter_specifications[2].output_parameters, 
“,parameter_specification.output_paranieters] 

# [parameter_specifications[2] .output_parameters, 

parame ter_speci fication .ou tpu t__parame ters] ; 
parameter_specifications[l].mode = 
parameter_specifications[2] .mode 
+1 parameter_specification.mode; 
parameter_specifications[2].mode_check = 
parameter_specifications[ 1 ] .m ode_check; 
parameier_specification.mode_check = 
parame ter_speci fications[ 1 ] .m ode_check; 
parameter_specifications[l].current_mode = 
parameier_specifications[2].current_mode; } 

I parameter_specification 

{ parameter_specifications.input_parameters = 
parameter_specification.input_parameters; 
parameter_specifications.output__parameters = 
parameter_specification.ou^ut_parameters; 
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parameter_specifications.inode = parameter_specification.mode; 
parameter_specification.mode_check = 
parameter_specifications.mode_check; 
parameter_specifications.current_mode = 
parameter_specification.current_mode; } 



parameter_specification 

: identifier_list type_mark 

{ parameter_specification.input j)arameters = 
[identifierjistvariable_names, “,type_mark.variable_type]; 
parameter_specification.output_parameters = *“*; 
parameter_specification.mode = {(“input_parameter”:”yes”)} 

+1 parameter_specificaiion.mode_check; 
parameter_specificadon.ciuTent_mode = “in”; ) 

I identifierjist IN type_mark 

{ parameter_specification.inputj)arameters = 

[identifierjist variable_names, “,type_mark.variable_type]; 
parameter_specification.output_parameters = 
parameter_specification.mode = {(“input_parameter”:”yes”)} 

+1 parameter_specificaiion.mode_check; 
parameter_specificauon.cuTTent_mode = “in”; } 

I identifierjist IN OUT type_maik 

{ parameter_specification.input j)aranieters = 
[identifierjistvariable_names, “: “,type_mark. variable Jype]; 
parameter_specification.output_parameters = 

[identifier Jistvariable_names, “: “,type_mark.variable_type]; 
parameter_specification.mode = ((“input_parameter”:”yes”), 
(“output_parameter”: ”yes”) } 

+1 parameter_specification.mode_check; 
parameter_specification.current_mode = “inout”; } 

I identifierjist OUT t)^_mark 

( paranieter_specification.inputj)aranieters = 
parameter_specification.output_parameters = 

[identifierjist variable_names, “: “,type_mark.variable_type]; 
parameter_specification.mode = ((“output_parameter”:”yes”)) 
+1 parameter_specification.mode_check; 
parameter_specification.ciiiTent_mode = “out”; } 

I identifierjist type_mark EQUAL expression 
{ parameter_specification.input_paranieters = 

[identifier Jistvariable_names, “,type_mark.variablejype];} 
I identifierjist *:* IN type_mark EQUAL expression 
{ parameter_specification.input j}aranieters = 

[identifierjist variable_names, “: ‘\type_mark.variable_type];} 
I identifierjist IN OUT type_mark EQUAL expression 
{ parameter_specification.input_parameters = 

[identifierjist variable_names, “: “,type_mark.variable_type]; 
parameter_specification.output_parameters = 

[identifierjist variable_names, “: “,type_mark.variable_type];} 
I identifierjist OUT type_mark EQUAL expression 
( parameter_specification.output_parameters = 

[identifier Jistvariable_names, “: “,type_mark.variable_type];} 



task_specification 

: TASK IDENTIFIER 

{} 

I TASK TYPE IDENTIFIER 

{} 

I TASK IDENTIFIER IS entry_declarations representation_clauses 
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END IDENTIFIER 



I TASK TYPE IDENTIFIER IS entry_declarations representation_clauses 
END IDENTIFIER 



{) 



entry_declarations 

; entry_declarations entry_declaration 

0 

I 

{) 



represen tation_clauses 

; representation_clauses representation_cIause 

{) 

I 

{) 



entry_declaration 

; ENTRY IDENTIFIER formaI_part 

{) 

1 ENTRY IDENTIFIER ‘(‘ discrete_range *)’ formal_part 



subtype_indication 
: name 

{subtype_indicationeVariable_type = name.variable_type; 
subt^ Jndication„element_type = name.element_type; 
name.generic_t)^s = subtype_indication.generic_types; 
subtype_indication.new_composite_types = 
name.new_composiie_types; ) 

I name constraint 

{subtype_indication.variabIe_type = name.variable_type; 
subt>^ Jndication.element_type = name.element_ty^; 
name.generic_t)^s = subtype_indication.generic_types; 
subtype Jndication.new_composite_types = 
name.new_composite_types; ) 



type_maric 
: name 

{type_mark.variable_type = name.variable_type; ) 



constraint 

: range_constraint 

{) 

I fixed_point_constraint 

{) 

I floating point constraint 

{) 

I discnminant_constraint 

{) 

I index_constraint 

{) 
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derived_type_definition 

: NEW subtype_indication 

{} 



range^constraint 
: RANGE range 
{} 



range 

: attribute 

{} 

I simple_expression TO simple^expression 

{} 



discriminant_constraint 

: *(‘ discriminant_associations ‘)’ 

{} 



discriminant_associations 

: discriminant_associations discriminant_association 



I discriminant^association 

{} 



discriminant_associalion 
: ex|pression 

I discriminant_choices ARROW expression 

{} 



discriminant_choices 

: discriminant_choices ‘I’ IDENTIFIER 

{} 

I IDENTIFIER 

{} 



generic_type_definition 
: ‘(‘ DISCRETE *)’ 

{ generic_type_definition.variable_type = “DISCRETE 
generic_type_definiiion.new_composite_types = ) 

I RANGE DISCRETE 

{ generic_type_definition.variabIe_type = “DISCRETE 
generic_type_definition.new_composite_types = ) 

I DIGITS DISCRETE 

{} 

I DELTA DISCRETE 

{} 

I array_type_definiiion 

{ generic_type_definition.variabIe_type = 
array_ty^_definition.variabIe_type; 
array_type_definition.generic_types = 
generic_type_definilion.generic_types; 
generic_type_definiUoii.new_composite_types = 
anay_type_definition.new_composite_types; } 
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I access_type_definition 

{} 



generic_instantiation 

: PACKAGE IDENTIFIER IS NEW name generic_actual_part 

{) 

I PROCEDURE IDENTIFIER IS NEW name generic_actual_part 

0 

I PTINCTION designator IS NEW name generic_actual_part 

{) 



generic_actual_part 

: ‘(‘ generic_associations ‘)’ 

{} 

I 

{} 



generic_associations 

: generic_associations generic_association 

{} 

I generic_association 

{} 



generic_association 

: generic_formal_paraineter ARROW generic_actual_parameter 

{} 

I generic_actual_parameter 

{} 



generic_formal_parameter 
: IDENTIFIER 
{} 

I STRING_LITERAL !operator_symbol 

{} 



generic_actual_parameter 
: exyression 

I name 

(} 



private_type_declaration 

: TYPE IDENTIFIER discriminant.part IS PRIVATE 
{ private_type_declaration.generic_type_declarations = 
[IDENTIFIER.%text,” : GENERIC.TYPESn”]; 
private_type_declaration.type_declarations = 

[“ “JD ENTIF IER.%text;’ : ADTNn”]; ) 

I TYPE IDENTIFIER discriminant_part IS LIMITED PRIVATE 

{} 



incomplete_type_declaration 

: TYPE IDENTIFIER discriminant_part 

{} 
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deferred_constant_declaration 

: identifier_list CONSTANT name 

{} 



attribute 

: prefix TIC attribute_designator 

{} 



attribute_designator 
: IDENTIFIER 
{} 

I IDENTIFIER ‘(‘ expression *)’ 

{} 



expression 
: relation 
{) 

I relation and_relations 

{} 

I relation or_relations 

{) 

I relation xor_relations 

{} 

I relation and_then_relations 

{} 

I relation or_else_relations 

n 

I 

0 



and_relations 

: and_relations AND relation 

{} 

I 

{} 



or_relations 

: or_relations OR relation 

{) 

I 

{} 



xor_reladons 

: xor_relations XOR relation 

{} 

I 

{) 



and_then_relations 

: and_then_relations OR relation 

{} 

I 
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{) 



or_else_relations 

: or_else_relations OR relation 



{) 

I 

{) 



relation 

: simple_expression 

{) 

I simple_expression relational_operator simple_expression 

{) 

I simple_expression IN range 

{) 

I simple_expression NOT IN range 

{) 

I simple_expression IN name 

{) 

I simple_expression NOT IN name 

{} 



simple_expression 

: term !Not really required because 3rd choice can break down to term 

{) 

I unary_adding_operator term 

{} 

I term binary_adding_operator binary_terms 

{} 

I unary _adding_operator binary_terms 

{) 



binary_tOTns 

: binary_terms binary_term 

{) 

I binary_term 

{) 



binary_term 
: term 
0 

I term binary_adding_operator 

0 



term 

: factor multiplying_operator_factor 

{) 



multiplyin^oi»rator_factor 

: multiplying_operator_factor multiplying_operaior factor 

{) 

I 

{) 
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multiplying_operator 

: TIMES 

{} 

I DIVIDE 

{} 

I MOD 

{} 

I REM 

{) 



factor 

: primary 

{} 

I highest j3recedence_operator primary 

{) 

I primary highest_precedence_operator primary 

{) 



highest_precedence_operator 

: EXPONENT 

{) 

I ABS 

{) 

I NOT 

{) 



primary 

: numeric_Iiteral 

{) 

I NULL 

{) 

I aggregate 

0 

I STRING.LITERAL 

{) 

I name 

{) 

I allocator 

0 

I function_caII 

(} 

I type_conversion 

{} 

I qualified_expression 

{} 

I ‘(‘ expression *)’ 

{} 



numericjiteral 

: INTEGER_LITERAL 

{} 

I REAL.LITERAL 

{} 



aggregate 
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: ‘(‘ component_associalions *)’ 

{) 



component_associations 

: component_associations component_association 

(} 

I cotnponent_associalion 

0 



cotnponent_association 
: expression 
(} 

I choices ARROW expression 

{) 



choices 

: choices ‘I’ choice 

{) 

I choice 

{} 



allocator 

: NEW qualified_expression 

{) 

I NEW subtype_indication 

{} 



funciion_call 
: name 
{) 

I name actual_parameter_part 

{) 



actual_parameter_part 

: ‘(‘ parameter_associations ‘)’ 

{) 



parameter_associations 

: parameter_associations 

{) 

I parameter_association 

{} 



parameter_association 



parameter_association 

: IDENTIFIER ARROW actual oarameter 

{) 

1 actual Darameter 

{) 



actual_parameter 
: expression 
{) 
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I name ‘(‘ name *)’ 

{} 

I name 



{} 



type_conversion 

: name ‘(‘ expression ‘)’ 

{} 



qualified_expression 

: name TIC ‘(‘ expression *)’ 

{} 

I name TIC aggregate 

{} 



relational_operator 
: EQUAL 
{) 

INEQ 

{) 

ILT 

{) 

ILTE 

{) 

IGT 

0 

I GTE 

0 



binary_adding_operator 

:PLUS 

{) 

I MINUS 

{} 

I AND !&, string concatenation 

{} 



unary adding operator 
:PLUS 
{} 

I MINUS 

{} 



multiplying_operator 

: TIMES 

{) 

I DIVIDE 

{) 

I MOD 

{) 

I REM 

{) 



enumeration_type_definition 
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: X‘ enumeradon_literal_specifications *)’ 

{) 



enumeration__literal_specifications 

: enumeradon_literal_specifications enumeradon_lit)eral 

{) 

I enumeradonjiteral 

0 



enumeration_literaI 
: IDENTIFIER 
0 

I CHARACTER.LITERAL 

0 



integer_type_definition 
: range_constraint 
{) 



real_type_definidon 

: floadng_point_constraint 

I fixed_point_constraint 

{} 



floadng_point_constraint 

: floadng_accuracy_definidon 

{} 

I floadng_accuracy_definidon range_constraint 



floadng_accuracy_definidon 
: DIGITS simple_expression 
(} 



fixed_point_constraint 

: fixed_accuracy_definidon 

{} 

I fixed_accuracy_definidon range_constraint 



fixed_acxuracy_definidon 

: DELTA simple_expression 

{} 



array_type_definidon 

: unconstrained_array_definidon 

{ airay_type_definidon.variable_type = 
unconstrained_airay_definidon.variable_type; 
unconstrained_airay_definidon.generic_types = 
airay_type_definidon.generic_types; 
array_type_definidon.new_coinposite_types = 
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unconsirained_array_definition.new_composite_types; } 
I constrained_array_definition 

( array_type_definition.variable_lype = 
constrained_airay_definition.variable_lype; 
constrained_array_definition.generic_types = 
anay_type_defi ni tion .generic_types; 
array_ty^_definition.new_composite_types = 
constrained_array_definition.new_composite_types; ) 



unconstrained_array_definition 

: ARRAY ‘(‘ subtype_definitions *)’ OF subtype_indication 
{ unconstrained_array_definition.variable_type = 
[“GENERIC_TYPE[BASE_TYPE: ARRAY[ARRAY_ELEMENT:’\ 
subtypeJndicauonxlement_type/\\n\tNlNlARRAY_INDEX:’\ 
subtype_definitions.index_type,”] ] ”] ; 
subtype_definitions.generic_types = 
unconstrained_aiTay_definition.generic_types; 
subtype_indication.generic_types = 
unconstrained_array_definition.generic_types; 
unconsirained_array_definition.new_composiie_types = 
subtype_definitions.new_composite_types +1 
sublype_indication.new_composite_types; ) 



subtype_definitions 

: subtype_definitions index_subtype_definition 
{ index_subtype_definition.generic_types = 
subtype_definitions.generic_types; 
sublype_definitions.index_type = 
index_subtyi^_definition.index_type; 
subtype_definitions[l].new_composite_types = 
subtype_definitions[2].new_composite_types +1 
index_subtype_definition.new_composite_typcs; } 
I index_subtype_definition 

{ index_subtype_definition.generic_types = 
subtype_definitions.generic_types; 
subtype_definitions.index_type = 
index_subtyi^_definition.index_type; 
subtype_definitions.new_composile_types = 
index_subtype_definition.new_composite_types; } 



constrained_array_definition 

: ARRAY index_constraint OF subtype_indication 
{ constrained_anay_definition.variable_type = 
[“GENERIC_TYPE[BASE_TYPE: ARRAY[ARRAY_ELEMENT:’\ 
subtype Jndication.element_type, 
‘^Jl^t\t\tARRAY_INDEX:DISCRETE]]’’^ 
subtyp)e_indication.generic_types = 
constrained_array_definition.generic_types; 
constrained_airay_definition.new_composite_types = 
subtype_indication.new_composiie_iypes; } 



index_subtype_definidon 

: name RANGE DISCRETE 

{ name,generic_types = index_subtype_definition.generic_types; 
index_subtype_definition.index_type = “DISCRETE”; 
index_subtype_definition.new_composite_types = 
name.new_composite_lypes; ) 
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index_constraint 

: ‘(‘ discrete_ranges *)’ 

0 



discrete_ranges 

: discrete_ranges ‘,’discrete_range 

0 

I discrete_range 

(} 



discrete_range 

: subtype_indication 

0 

I range 

(} 



record_type_definition 

: RECORD component^list END RECORD 

0 



component_list 

: component_declarations 

{} 

I component_declarations variant_part 

{} 

I variant_part 

{} 

I NULL 

{} 



component_declarations 

: component_declarations component_declaration 

{} 

I component declaration 

{} 



component_declaration 

; identifier_list subtypejndication 

{} 

I idendfier_list subtype_indication EQUAL expression ‘ 

{} 



discriminant_part 

: ‘(‘ discriminant_specifications *)’ 

{} 



discriminant_specifications 

: discriminant_specifications discriminant_specification 

{) 

I discnminant.specification 

{) 



88 



discriminant_specification 
: identifier_list name 
{} 

I idendfierjist name EQUAL expression 

{} 



variant_part 

: CASE IDENTIFffiR IS variants END CASE 

{} 



variants 

: variants variant 

{) 

I variant 

{} 



variant 

: WHEN choices ARROW component_list 

{) 



choice 

: simple_expiession 

0 

I discrete_range 

{) 

I OTHERS 

0 

I IDENTIFIER 

{) 



access_type_definition 

: ACCESS subtype_indicadon 

{) 



name 

; IDENTIFIER 

( name.variable_type = IDEN l'lFIER . %text; 
name.variable_name = IDENTlHER.%text; 
name.element_type = name.generic_types(ID ENlIH ER.%text); 
name.index_type = name.generic_types(IDENTIFlER.%text); 
name.new_composite_types = {(IDENTIWER.%text: “yes”)}; ) 

I CHARACTER_LITERAL 

(} 

I STRING_LITERAL !operator_symbol 

{} 

I indexed_component 

{) 

I slice 

{} 

I selected_component 

{} 

I attribute 

{} 
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prefix 

: name 



I function_call 

{} 



indexed_component 

: prefix ‘(‘ expressions *)* 

(} 



expressions 

: expressions expression 

I expression 

0 



slice 

: prefix *(* discrete_range ')’ 

0 



selected_component 
; prefix selector 
{) 



selector 
: ALL 
{) 

I CHARACTER_LITERAL 

U 

I STRING_LITERAL !operator_symbol 

{) 

I IDENTIFIER !simple_name 

{} 



identifierjist 

: identifier_list IDENTIFIER 
{ idendfier_list[l].variable_names = 
[i dentifie r_list[2].variable_names/\ “ JDEN 1 IFIER. %tex t] ; } 
I IDENTIFIER 

{ identifier_list.variable_names = IDEN liFlbR.%text; } 
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